IRF

In any case, I feel sure that Danny will help to publicise the release of the bug-fixed version of the game at the Expo in Manchester this weekend... :)

Well that's true! In that sense, it continues a fine tradition!

I suppose if the non-completable version was to win, without the completable version being widely known about, then it might ultimately lead to a certain amount of dissatisfaction in the result.

Save it for a red-letter day. ;)

I see that 'Maria vs Some Bastards' has been nominated for the 'Favourite JSW Mod' award. Hopefully it will be looked upon even more favourably now that it's completable! ;)

Has no-one spotted this yet?

View File Maria vs. Some Bastards 2019 Bug-Fixed Edition Maria vs. Some Bastards is a beautiful game by Vidar Eriksen (Erix1). It uses a modified JSW48 game engine that has come to be known as 'Erix1 Mode'. Its first short demo version was released in October 2001. The game was gamma-released on 6th March 2003, with four bug-fixed revisions (called Rev B, C, D and E) released within the next few weeks. A menu screen implemented by the BASIC loader allows the player to choose one of the three modes: Easy, Normal or Hard. According to the message which shows in the opening room, you need to collect 120 items to complete the game if you choose the Easy mode, 240 items if you choose the Normal mode and 246 items if you choose the Hard mode. Daniel Gromann raised the question of the game question of the game’s completability on the Manic Miner Jet Set Willy Yahoo! Group in June 2007, when he pointed out that Maria did not disappear after he had collected 251 items in the Hard mode. In March 2012, Vidar Eriksen promised to look into the problem and check whether some ‘end-game corrections’ he had done in Rev D were not left out in Rev E. He mentioned that a Rev F might be necessary, but it did not materialise in the following years. Ian Rushforth investigated the item-collecting code in Maria vs. Some Bastards and discovered the cause of the bug which made the game non-completable. He announced his findings on Manic Miner Jet Set Willy Yahoo! Group in February 2019, offered a bug-fix for the problem and also showed the way to collect one of the items Daniel had not been able to reach. After some further discussions, the Jet Set Willy Manic Miner Community Team produced a 2019 Bug-Fixed Edition of the game, with the following changes in relation to Rev E: - Ian’s solution to the bug in the item-collecting code was applied. - A way was provided to collect the rightmost item in the room "Stinking sewer" (27), which seems impossible to collect in Rev E. - Three items located in the very same (non-)rooms which are used by the Softricks game engine (on which Erix1 Mode is based) to store the item table - which are thus invisible and unreachable in Rev E - were moved to other locations so that they became present in the game and collectable. - As the total number of items possible to collect has now reached 256, the number required to complete the Hard mode was set to 256, with the corresponding changes in the BASIC loader and the message in “Master Bedroom”, where the game starts. - An item placed in the same location as another item (as happens in “The Beach” in the original JSW) in the room “Afterliving” (46) was moved within the same room to make its collection more demanding and make the player use a route they might not use otherwise. - A minor change to the layout of “Alien inferno 2" (49) was applied to force the player to press the special button in that room if they want to complete it without losing a life. - The middle item in the room “Bubbles and Bob” (41) was moved to make its collection more meaningful. - The up exit from "That slimy room" (11) was changed to itself instead of "The dungeon" (00), in order to prevent the protagonist from potentially getting perpetually stuck at the bottom-right corner of the latter room. - The spellings of the room names “Flooding sewer” (15), “Seagull corner” (36) and “Deadly descent” (54) were corrected. - A typo in the scrolly for Manic Mining Robot's Day Out, the ‘secret bonus crap game' attached to Maria vs. Some Bastards was corrected. - Information about this being the 2019 Bug-Fixed Edition was added on the loading screen and in the REM statements in the BASIC loader. - The Readme was also updated with the info that this is the 2019 Bug-Fixed Edition. All of the above changes were applied to the actual game file by Ian Rushforth, after some deliberations with Andy Ford and Daniel Gromann. We hope you will enjoy this Bug-Fixed Edition and the ability to complete Maria vs Some Bastards at long last. Have a go at it - it’s worth it! 🙂 Submitter IRF Submitted 04/13/2019 Category JSWMM Releases  

I notice there's also a mention (near the end) of Manic Miner: The Boardgame! (I think it's a joke though.)

Upon dying, the JSW64 'No Kamikaze' feature also takes the item count* back to where it was before you started collecting items in the 'No Kamikaze' room. So there's no danger of the total number of items collected running past what it should be. (*Both the internal item count variable and the ASCII tally on the status bar.)

I'll second Andy's comments. It's a great resource, Danny! :)

JSW64 's 'No Kamikaze' feature, applicable on a per-room basis, is a similar concept to your latter suggestion. With regards to the former idea, like you say it could make Eugene's Lair uncompletable, if you collected all items then lost a life before reaching the portal. (The start position in the cavern is too far from the portal if Eugene is angry from the outset!)

If you're looking for amateurs who haven't completed Jet Set Willy, then you've come to the wrong place! ;)

This is meant to be an analogous POKE to the Jet Set Willy Superjump? As I explained in the post in the following link, that POKE is flawed: http://jswmm.co.uk/topic/57-pokes-spectrum-version/?p=7146 The equivalent POKE for Manic Miner should take the program to #8C57, so the POKE should be: POKE #8B0E, #57 or POKE 35598, 87 in decimal [bug-Byte Edition] POKE #8B14, #64 or POKE 35604, 100 in decimal [software Projects Edition] EDIT: I've taken the liberty of editing Andy's previous post to reflect this.

I'm aware that there are large areas of the title screen with many consecutive identical attribute values (e.g. the first two character rows all hold 00), where it is much more efficient to use a few simple loops to write the appropriate values to the 'uniform' parts of the screen, instead of storing whole chunks of repetitive data (e.g. 64 consecutive 00 bytes for the top two rows) and copying the whole screen using a single LDIR command (as was the case in the original code). EDIT: That is to say, the amount of bytes saved in optimising the storage of the Title Screen's attribute data, vastly outweighs the modest saving which I have just come up with for the routine that draws the Impossible Triangle's pixels based on the attribute data.

There follows a disassembly of my rewrite of the Impossible Triangle-drawing code, as mentioned in my previous post. The rewritten part of the routine now saves eight bytes, compared with the original. N.B. I believe that this is exactly the sort of thing that the CPIR command should be used for (unlike Matthew's dodgy application of CPIR in the room-drawing code, which gives rise to the Cell Graphics Bug). Title_screen_data EQU #885D ; A new data table, which contains all the attribute values which were individually checked ; via CP #nn commands in the original code (and the former operand of a LD A, #nn command) Triangle_graphic_data EQU #8431 ; The original table containing the pixel-graphics used to create the impossible triangle. ; There are two halves to this table (at #8431 and #8441), and each half contains a pair ; of two eight-byte graphics (e.g. graphics start at #8431 and #8439 for the first half of the table) ORG: #8841 LD DE, #5800 Impossible_triangle_loop: LD A, (DE) LD HL, Title_screen_data ; HL now points at the start of the data table, in preparation for the CPIR loops (and other commands) that follow LD BC, #0005 ; BC counts down the CPIR loop, but B is also used to indicate which half of the graphic data at #8431 is picked up CPIR ; Search through the first five entries in the data table JR Z, Nothing_to_draw ; If there is a match, then this particular screen cell contains no pixel-graphics LD C, #03 ; B still holds 00 at this point (and HL is pointing at the next part of the data table) CPIR ; Search through the next three entries in the data table JR Z, Draw_triangle_segment ; If there is a match, then draw a part of the triangle using the first half of the graphic data at #8431 CP (HL) ; Check A against the penultimate value in the data table... INC HL ; ...and move HL on to the final entry in the table (I tried a CPI command here, but that doesn't preserve B = #00) JR Z, switch_INK_and_PAPER ; If there is a match with the penultimate entry, then we are at the 'tricky corner' of the triangle LD B, #10 ; No match in the data table, so we need to select a graphic from the second half of the pixel data JR Draw_triangle_segment ' (i.e. the parts of the triangle which slope 'up-to-the-right') Title_screen_data: ; This table could be moved elsewhere in the code, but every path through this routine jumps past it, ; so it can safely be left here DEFB #00 #09 #24 #2D #D3 ; These entries correspond to parts of the screen with no pixel-graphics (i.e. the black background, flashing lettering, ; or solid parts of the triangle which have matching INK and PAPER colours) DEFB #05 #08 #29 ; All remaining entries in the table correspond to parts of the triangle which slope 'down-to-the-right' DEFB #2C #25 ; If the attribute in the cell under consideration is #2C (green INK/cyan PAPER), then replace it with #25 (cyan INK/green PAPER) ; N.B. I could have save an extra byte by retaining the original commands for the last two entries [CP #2C and LD A, #25 / LD (DE), A], ; and omitting the last two entries in the table, but I considered it more elegant to have all the data stored within a single data table DEFS #08 ; Eight unused bytes (NOPs) - the point of the exercise! (These can obviously be consolidated elsewhere) Switch_INK_and_PAPER: LD A, (HL) ; Pick up the final entry in the data table and update the attribute in this cell (this swaps the INK/PAPER colours around... LD (DE), A ; ... which allows the green/cyan corner of the triangle to be drawn using all four of the graphics at #8431) ; N.B. From hereon in, there are further byte-efficiencies to be achieved, which are documented earlier in this thread, ; but which I haven't (yet) incorporated below Draw_triangle_segment: LD A, E AND #01 ; Whether E has an even or odd value determines which half of the selected pair of graphics from #8431 is used RLCA RLCA RLCA OR B ; Determines which pair of graphics from #8431 is used (N.B. this has been changed from the OR C in the original code) LD C, A LD B, #00 LD HL, Triangle_graphic_data ADD HL, BC PUSH DE BIT 0, D LD D, #40 JR Z, correct_part_of_screen_identified LD D, #48 Correct_part_of_screen_identified: LD B, #08 CALL #969B POP DE Nothing_to_draw: INC DE LD A, D CP #5A JP NZ, Impossible_triangle_loop EDIT: I should also mention that the above rewrite still works if the erroneous attribute in the original title screen is corrected (i.e. the green/black cell inside the lower part of the letter 'S', which should properly be green and blue). This can be fixed by editing the data at source, within page #98 (i.e. POKE #98D2, #0C) - no change to the new table at #885D is required, because the corresponding triangle segment slopes down-to-the-left, and so it doesn't need a specific entry in the table (the correct graphic is selected 'by default').

Here are the POKES (in hexadecimal) that will fix the 'Skylabs Bug' in 'Ultimate Manic Miner': Memory Bank 3: POKE #FE07, #78 POKE #FE08, #8C POKE #FE0F, #78 POKE #FE10, #84 POKE #FE17, #78 POKE #FE18, #8C Memory Bank 6: POKE #F6A7, #78 POKE #F6A8, #86 POKE #F6AF, #78 POKE #F6B0, #86

I've found a six nine-byte saving in the 'Initialise the title screen' routine, by replacing the individual checks of various attribute values at #8844-#8870, inserting a couple of look-up tables and using two CPIR commands. I'll type up a disassembly when I find the time. :)

Norman did actually report it via an edit to post #21 (top of this page), but it's easily missed.

There's only one game file attached to post #1 now, so that'll be 'the one'!

POKES for JSW2-style jumping (with more dynamic turns): POKE #840C, #03 POKE #840E, #03 POKE #8411, #02 POKE #8413, #02

POKES for JSW2-style jumping (with more dynamic turns): POKE #8425, #03 POKE #8427, #03 POKE #842A, #02 POKE #842C, #02

Actually, I think that might've been a reference to the post [first post in this thread] having been updated with screenshots added for every room (prior to that point it only showed the new rooms, and it had omitted to show the new room 47).

By "the delay routine", are you referring to some other part of your modified version of the program, which uses (in part) the common subroutine to extract data in a similar manner? As well as the spare bit that you identify, I think the highest bit is also spare, since there are only 16 entries in the NOTE_SHIFT table (which therefore only requires 4 bits)?

I managed to prevent a piano key from lighting up during the pause in the tune, in an update to 'Manic Mixup' (available in the Downloads section here). I think my method was different to yours though.