Jump to content
Jet Set Willy & Manic Miner Community

Spider

Moderator
  • Posts

    5,225
  • Joined

  • Last visited

Everything posted by Spider

  1. 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.
  2. 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 πŸ™‚
  3. 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"
  4. @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.
  5. πŸ™‚ 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
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. Ah OK. πŸ™‚ It was an unrelated idea to increase the game speed a bit.
  11. That's correct, first time pass. πŸ™‚ C1 + Page 2 = R/Y/R/Y , 2/6/2/6
  12. Is there any unused space in the game code ? As in , you've not used much of the dead space within the game itself ?
  13. 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! πŸ™‚
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. I wonder if I should of altered the code, its only changed iirc for cavern choice on startup*** so it didn't gain more lives, however as you've found ( well done πŸ™‚ ) eventually the lives will spill over into the playing area preventing further progress. *** I could of I suppose with some work done the level select in the code, ideal world being it asked upon game start which cavern you'd like rather than at the moment a bit of Basic to alter it then fire the code up. EDIT... Good choice of Sam version music , 99% sure its that. πŸ™‚
  20. I did remove (merely out of curiosity) two halt instructions I noted and the speed was insane however that was not the point , I wanted to see it like that, then I put them back. πŸ™‚
  21. This looks very good. πŸ™‚ Although a small (relatively) change the font is excellent too especially on the cavern name area.
  22. I'm interested to see this too. πŸ™‚ I found a reasonable speed increase by a more efficient method of the four main copy routines and combined with (in my case) storing the source screen data outside contended ram also made a good increase*** *** To do the latter, I cheated as a test by disabling contention in emulation, but it gave me a good approximation of what it would do. Must admit I'd not read that thread other than maybe a couple of posts when it first appeared as I'd assumed it was only about sprite designs nothing else. πŸ™‚
  23. No problems at all, it had to be really I think , unless his site was having some odd issues. Great. πŸ™‚ Looking forward to you hopefully sharing some of your work when you're ready to.
  24. Works fine on W10 (and W7 too, I can't recall if there were any issues with W11 and I don't have a 'box' to check that at the moment) I'm not sure why you can't actually download it, that sounds more like a browser issue ? Perhaps either wait a short time and try again or if you can and have one installed try another browser ? πŸ™‚
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.