Spider

Over at Spectrum Computing: https://spectrumcomputing.co.uk/forums/viewtopic.php?p=155579 Must admit I knew most but not all of these methods, although it was not something I had really thought about doing or trying. It is interesting to see some variations however. Thought I'd share here. 🙂

Although a different game, with JSW it makes Forgotten Abbey a little bit more tricky (the bottom row jumps) In MM I did note that Skylabs , Warehouse and to some degree Amoebatrons Revenge were all slightly more difficult given the precise nature needed in these, the former two especially. I couldn't really say that Solar Power was any harder as it is all about 'player' speed in that cavern, too much hesitation as you know and there's no air left! 🙂

Those disassemblies don't cover the 64/128 variants. As far as I know (and its limited, as above) JSWED doesn't provide any inbuilt means to do much with the extra memory, by this I mean it uses it itself for the extra rooms/sprites/music. I've not looked at the documentation to see if its covered which pages (pages of memory) it uses. If you are just wanting extra guardians per room or suchlike, there is a quite a variance in the 64/128 versions as I recall, that is listed in the .pdf itself. I suspect its not quite that simple though. 🙂

It could go a LOT faster with rewriting the main loop and more importantly moving the buffer data areas out of contended memory. But I sort of think too fast could be annoying. The contention can be 'emulated' (as in disabled) in ZXSpin at least. Thank you I appreciate your kind reply. 🙂 The 'extra' bonus stuff was really just boredom I think. The linked post shows the 'changes' which are very minor (no pun) aside bonus incrementation/air levels. V2 does not have these extra scoring elements.

I've not really looked at the 64/128 variants sorry. The actual 'running code' is quite near the original 48K version, not quite the same but not miles away from it. I base this on the fact that some of the original game pokes do function on these variants, but not all. The actual extra memory will be paged in (and out again) as require, as 16K blocks into the upper memory area. The later black plus2 and plus3 are a bit different iirc but this is really about switching something into what was the rom area. I've very little (if any practical) knowledge of the 128 paging as I've never had need to use it myself. If you can say what you're trying to do / would like to , perhaps someone can provide further guidance. 🙂

Further to my post on page two here , I decided for no real reason to change the scoring and add a bit more air, as well as compress the code to reduce it's loading size. There is a lot more scope to optimise this, it is starting to 'click' now properly with me. For now , two identical versions with the increased bonus/air , one with a loading screen and one without. Without screen$ MM_SP_Faster V3_EXTRA_BONUS_WITHOUT_SCR.tap With screen$ MM_SP_Faster V3_EXTRA_BONUS_WITH_SCR.tap The game code is identical in each of these two. For reasons of sanity I've named it 'V3' as the one in the linked post is V2 And a quick playthrough: MM_SP_Faster V3_EXTRA_BONUS_WITH_SCR.rzx .rzx recorded with Spectaculator, it should play back fine in most other emulators I expect.

It works in reverse too (at least I recall trying this once) if you place an invisible item in the path of a white guardian or an arrow , said item is collected for you. Good one is the 'bug fix' to move the object from First Landing to Hall, its not got a shape defined. Moving an arrow to collect it would work. From the disassembly: 93EC LD A,(DE) Pick up the current attribute byte at the item's location 93ED AND $07 Is the INK white (which happens if Willy is touching the item, or the room's background tile has white INK, as in Swimming Pool)? 93EF CP $07 93F1 JR NZ,$9430 Jump if not Another way of looking at it, from Basic although this misses a lot out and makes some assumptions: IF ATTR (x,y) = 7 THEN collect item ^ We are assuming here x,y is the location of the item on the screen and that we have black paper and white (non bright) ink aka colour code 7 , if it was bright it would be 71 (decimal) Its seen in Swimming Pool as mentioned. The easy fix for that is to simply change the background ink to non white, green seems appropriate as Orangery is above.

Danny does raise some good points about the in-game tune being altered by this, similar perhaps to running your emulator at say 150% Some tunes do sound better with a bit of an increase in speed but not that many, I do think a 10% to 30% increase may not ruin it much (see the MM file I posted in the optimisation topic) ? J S W , I did provide instructions but I'd have to find them or write them out again, its not difficult and its actually in my head 🙂

The walkthoughts were possibly (likely?) mine, I've done several. Certain rooms however when the bug is in effect do seem to make it deteriorate a bit faster, notably "Inside the MegaTrunk" , staying here and switching emulation speed up a bit (200% is fine) you'll see the status bar start to corrupt. Kitchens can have a similar effect, although the guardians moving horizontally at that stage is erm distracting. A sidenote about the other "big three" bugs: I think half or most of the battle is Banyan Tree, if it were possible to jump from the left side and catch onto a water cell without hitting a guardian, you could then climb it. The "First Landing" object something would have to be done or the item count adjusted to ignore it, same perhaps as "Conservatory Roof"

@DigitalDuck A few years ago now I had a very very old memory of playing that game (when it was new!) at an arcade on holiday but moving back to recently I could not remember what it was called but the tune did stick in my head. I know there's two of them , the original and the 'new' , I actually have it on Mame and play it every few weeks. I'm still terrible at it! 🙂 Also its "another good Z80 CPU" game too.

🙂 No, because Manic Miner was first by a fair way (a year or just under I think) which discounts the "JSW First" part of it. 🙂 I'm also not convinced at all it was the first game to have an in-game tune that "played continuously" during play either, but I would need to research that to find an 82 or early pre-June*** 83 game that did. It could be the first ZX game to do this but as said I'm not convinced. *** I'm only about 90% sure on that month, the Software Projects re-release of it was late 83

One of Matthew's early games, the Spectrum version is readily available but this was not: https://www.gamesthatwerent.com/2024/09/monster-muncher/ An interesting read at least.

I never got around (sorry) to actually comparing them. I don't currently own the original JSW2FF Spectrum release*** I had assumed they were the same because unlike other Software Project games that use the 'keypad' type code, the colours for the Spectrum and Amstrad versions were the same (colours) aka: Blue / Red / Yellow / Green (CPC) Blue / Red / Green / Yellow (ZX) Ocurred to me the reason for the slight difference is because the CPC has them slightly differently ordered: Blue/Yellow/Green/Red (Pen value and keys 1,2,3,4) Blue/Red/Green/Yellow (Ink value and keys 1,2,4,6) Sorry for the truncated picture but I wanted to see them side by side, I don't have any decent tools installed currently: *** I do have it somewhere I thought in my clearout I'd find it but alas no.

I'd have to look but I think most MSX versions would of had a "enter any code you like" type of fix as its one byte only usually to do this. I've not seen (lately) the MSX codesheet so I cannot be sure, I do remember Manic Miner MSX had a sheet though too, and so did the BBC Micro version.

Small amount of space is needed, not a lot. For an idea, please load a standard Manic Miner game and just move about in the first cavern (or play it) , then load this one and do the same please.

Ah OK. 🙂 It was an unrelated idea to increase the game speed a bit.

That's correct, first time pass. 🙂 C1 + Page 2 = R/Y/R/Y , 2/6/2/6

Is there any unused space in the game code ? As in , you've not used much of the dead space within the game itself ?

I recorded it in Spectaculator. This does not play back in Spin. Can redo if needed. I set Spectaculator on flash load , using the 48K model and just recorded the whole lot to the title screen. Its the original tape not the re-release*** so it asks for a code which I provided (yes the correct one, the code was not modified) jsw2_spectac.rzx I re-did this in Spin , its the whole lot , but you can save as video and trim down. It did not speed up loading for some reason with this emulator. Note I had to record this in 128K (Sinclair toastrack model) because my Spin 48K rom is quite modified whereas the 128K one is not. jsw2_spin.rzx Please say if anything needs redoing. Note I failed the first key entry, my fault. *** Re-release, its quite different. The original should be one short piece of Basic containing the loader then a large headerless block, nothing else. The re-release tends to be about 3 pieces of code to 'bypass' the keycode. Best I can remember with this version (re-release) without having looked into it in details for many years is its a snapshot in effect of the game at the title screen. This was -not- used here for the above, only the original tape. complete with seven pages of keycodes! 🙂

So we can see it soon ? 🙂

Should not need to repeat the CLEAR 🙂 With ZXBasic its extended mode (assuming 48K Basic) then symbol shift and 3 together to get the keyword LINE With ZXEDitor (block editor anyway) you can choose a type of header "compose datablock" and pick either tzx or tap to match and choose "program autostart header" instead of "program header" I did see some files you sent a while ago but due to (other issues) I can't process multiple copies of things at the same time 😞 One "full" tape file and I should be able to sort it.

What (where is it loaded) is the piece of code in line 100 of the second program ? You'd need CLEAR 32767 at a minimum really that will give plenty (ish) Basic space and let the main codeblock load at 32768 You're correct, 'load' the second one which will overwrite the first, i am thinking here -if- the second program does -not- have a LINE xyz to start it, as the original has been overwritten it -might- try to continue onwards from the program line counter instead of the start of it... if it was loaded in a new reset machine it would load and not do anything without a LINE however if something is already there... so if you had say line 200 (example) in the first program of LOAD "" , like 200 LOAD "" (load the next bit) and the second program did -not- have a LINE when saved... it -might- start running at line 201 in the -new- program. Its hugely preferable to add LINE xyz unless merging so that it won't confuse the basic interpreter. The issue could be as simple as something like that. I'm not sure how Basic will deal with a new piece of Basic without an autostart line number that is loaded (not merged) , assuming the old and new share a line number it may even start executing the 'new' Basic at the next statement in the line that was used in the old program to load it.

Had added a bit while you were typing @DigitalDuck 🙂 , Wrong error I meant to say "out of memory" not "no room" , that one I saw a lot of with 16K 😄 , but yes. The merging (if it is being merged) is usually reliable but I've not really had to ever use that "in anger" as such with a lot of Basic. I do agree if its throwing that kind of interpreter error it might be changed while running, a good thought. Not hard to poke a value in , while in Basic but actually accidentally*** change something. As you know what is 'shown' is not always what is executed, numbers certainly, example: not_what_list.tap *** Was done a bit on some custom protection schemes iirc , much obfuscation... But here in this case for the O.P its not intentional . I do suspect you're right in perhaps a stray POKE or similar is doing something, easily done with a typo.

What is on line 100 Are you merging the second Basic into the first aka MERGE or are you loading it ? I'd expect it to fail with tape loading error if there was not enough space because ramtop was too low (technically a bug as it should say "no room" or similar iirc) Another possibility is any code being loaded low down has overwritten part of the Basic too but in that case it tends to (if you can do it) make a complete mess of the listing.

Yes I realised after I'd posted*** that it was locked to one level only. It does show how far you can go though. Although it is without a speed up terribly slow once you have a full row or more of lives! 🙂 (and temporarily lost internet) aka restart because someone aka me "forgot" to enable a couple of Bios features oops.