IRF

... And it seems I got completely the wrong end of the stick! The number of T-States for a conditional relative jump loop is based on how many times the relative jump has to be executed (here determined by counting down the value of A, which doesn't change between Norman's method and mine), rather than the distance back through the code that each relative jump spans (the operand of the JR command), as I had previously understood to be the case. :blush: So Norman's code (featuring only one CALL and RET per chunk of code copied) is certainly faster than my version!

On reflection, my variant might not be faster after all - my subroutine is CALLed #10 or #80 times during every pass through each part of the Main Loop that performs a block copy operation. The number of T-States for that many CALL/RET commands (versus just one CALL/RET in Norman's code) may well outweigh the saving in T-States achieved by shortening the length of the relative jump! Further investigation is required...

A query [EDIT: Which I think I've answered myself in subsequent posts!]: In the Main Loop of a recent project, I have this arrangement (repeated four times, for copying pixels twice and attributes twice - primary to secondary buffer and then buffer to physical screen): LD HL, source LD DE, destination ; No need to define BC; it's not used now, so LD BC, xxxx command has been deleted LD A, #80 or LD A, #10 ; For copying the pixels (128 raster lines) or attributes (16 character rows) respectively loop: CALL subroutine DEC A JR NZ, loop ; Once A reaches zero, flow of execution continues through the Main Loop The subroutine which is CALLed consists of 32 consecutive LDI commands, followed by a RET. This was obviously based on one of Norman Sword's suggestions (duly credited in the readme file for the project in question). However, there is a slight difference - Norman's subroutine incorporates the DEC A and JR NZ commands (after the final LDI and before the RET), whereas in my version, those commands are located in the Main Loop. In terms of memory, Norman's version is obviously more efficient (because I have to repeat the DEC A and JR NZ commands four times within the Main Loop, rather than just once in Norman's subroutine). However - and here is my query - would my version be slightly faster? [i don't mean the game as a whole - Norman has done lots of other things to speed up the game - I mean purely in terms of comparing the two variants of the LDI method like-for-like.] My thinking is that the number of T-States which it takes to perform a relative jump is proportional to the distance through the code which has to be jumped - 67 bytes in Norman's case, and only 5 bytes in mine. ? **** N.B. My method may complicate things in cases where a chunk of code is being overwritten with a single value - where the first byte is overwritten directly and then the number of bytes to which the same values is to be copied in a loop is minus one. e.g. for attribute update with a single value (such as for a screen flash effect), use #01FF instead of #0200 to define the size of the loop. Norman's code deals with such cases by CALLing a late entry point into his subroutine, coinciding with the second LDI command in the subroutine. (But the JR NZ at the end of the subroutine jumps back to the first LDI in the subroutine.) In such cases, I think my method would unavoidably end up 'overshooting', and overwriting one more byte than it should. (But in the aforementioned project, I didn't actually use an LDI method for 'block fill' purposes, only for 'block move'.) EDIT: For reference: http://jswmm.co.uk/topic/375-a-total-rewrite-of-jsw-in-48k-using-matthews-core-code/page-4?do=findComment&comment=7745 Note also my comment/query here about a couple of presumed typos: http://jswmm.co.uk/topic/375-a-total-rewrite-of-jsw-in-48k-using-matthews-core-code/page-6?do=findComment&comment=9047

It's okay, I don't mind leaving the clues! By the way Andy, did you try to solve the rest of the puzzle yet (without watching Danny's recording)?

Anyway, I'm glad you both enjoyed the puzzle! There are three things left for me to explain (at a later date): 1 - How the 'hidden' message is implemented (and why it is only visible sometimes); 2 - How the feature which it is alluding to is implemented; 3 - The implications for the most efficient route through the layout (Danny may figure this out for himself!)

Since Andy has now grabbed Danny's recording, I've taken the liberty of removing it from his post. I'd rather it wasn't freely available as it's a bit of a giveaway when the sole focus of the recording is that manoeuvre. (I don't mind the manoeuvre being shown in the context of a complete walkthrough of the whole game to submit to the RZX Archive, where it would be 'buried in the mix'.)

I think you've missed a whole page of 'developments' there, Andy!

Well done on completing the third and final part of the puzzle, Danny! Hopefully Andy will also be able to independently perform this feat before he watches your recording. (Another little clue: .) It's more a case of 'getting you back on track' with your usual preferred route. You're welcome! :)

Well done on cracking Part 2 of the puzzle Danny! Now for Part 3 - find the secret exit from 'The Nightmare Room'! :-) (You already made a start on trying earlier!) I'm back off to bed now (a nightmare awoke me!!)

No, you need three words,

It's a secret! ;-)

Need another clue?

Danny, you are right that the message isn't always visible in 'The Nightmare Room' - it is always present, but not always visible (for a reason which I will explain at a later date, as it's a bit of a distraction right now). However, the thing that the message relates to isn't affected by whether or not you can see the message. You're definitely thinking along the right lines though. :) Getting closer to cracking the puzzle... Andy's already guessed that there's an anagram involved. EDIT: I'll save you a bit of head-scratching by pointing out that if you "compare the left-hand and the right-hand side of the message", you will see that they both contain the same combination of letters. So the anagram is repeated twice (in two configurations) across the character row. i.e. You need to look for one phrase, which is an anagram of both: 'EXISTENCE DRIFT ' and ' FIXED INTERSECT'

My replies, appropriately enough, in red:

So, you've finally solved Part 1 of the puzzle! Now for Part 2 - what is the meaning of this mysterious message??

You've got it! There is a message written across the status bar of 'The Nightmare Room'! I'm amazed that no-one has noticed it before! It brings to mind this notorious psychological / observational test: https://en.wikipedia.org/wiki/Inattentional_blindness#Invisible_Gorilla_Test The message is comprised of words/letters written in red INK - hence all the clues to that effect. 'Outside the box' / 'big picture' because it's not contained within the playing area/room layout, where I guess everyone's focus tends to be when playing the game. (BTW You had the wrong end of the stick looking for a bouncing letter sprite, Andy - that's in a different game: 'The Bank' in Manic Mixup! :lol: )

BIG clue:

All the clues relate to the same thing! You're very close with something you've said there...

A small clue: Try to look at 'the bigger picture'... Another clue: Think 'outside the box'... And don't forget about all the earlier clues I left in this topic... EDIT: Here's the link again - study the screenshots: https://jswcentral.org/jsw48-a-48_mini.html

Yes indeed! It's something that no-one has discovered yet!

Andy, have you had a chance to go through the screenshots yet this weekend? Do you want another clue (a big one)?

Well done Danny? May I ask: did you download the game for this playtesting? I made a small tweak to the game file back in January (I think), to fix a small glitch/bug in the Title time routine (and to update the reader to give you credit for the Easy/Hard POKES idea, implemented differently here from JSW40-40). That change didn't affect the gameplay in any way, so it doesn't matter if you used an earlier version.

None of those things are what I have in mind Danny. But Andy has told me (in a PM) that he is going to have a look this weekend - it's a glaringly obvious thing and you'll kick yourself once it's been pointed out to you! Hopefully once part one of the puzzle has been solved, you might feel intrigued enough to try to crack parts two and three... In terms of a RZX recording, I would urge you please to hold off for a little bit longer - your completion time (and enjoyment of the game) will benefit from it!

The puzzle is in three parts (if you count spotting the visual clue in the first place as the first part).

Thanks Norman. As it happens, in example 1, if the initial value held by S_M_C_counter1 was zero, then it would quickly be overwritten by 8 and then it would return to the intended pattern of the operand incrementing during each pass through the code (looping back from 15 to 8). (The initial value of zero might have an adverse impact though, depending on the context - especially if the variable is picked up by the program before it is first modified. e.g. an out-of-range guardian crashing into a wall at the edge of a room?) But I can see that in example 2, if you had a default value of zero stored at S_M_C_opcode, then execution of the code would never cause the labelled address to reach either of its intended operations (INC A or DEC A). Instead, the address S_M_C_opcode would toggle between acting as a NOP (00), and the 01 opcode - which would have the unintended effect of picking up the next pair of bytes which follow on from S_M_C_opcode, and loading those values into the BC register-pair!