Norman Sword

When I finished version 1 of Manic Jet Set Willy. I was already aware of a problem - which was subsequently mentioned by others. The problem was caused by the editor having a column mode. Which I use occasionally to copy data and very rarely to delete data. The problem with using the column mode is the editor allows hard tabs and spaces to exist in the same text. The column mode struggles to understand where the visual columns are and as a result can do strange things. What it highlights and what it does are two differing things. At some stage during the last release of MJSW (Manic Jet Set Willy) I deleted a great quantity of old code and at the same time deleted a good deal of the comments that, due to editing, meant nothing for the code displayed. So I casually deleted a great deal of obsolete comments by using the column select and delete method. What I had not noticed was the delete has a bug in it. Which is different to the mess it normally creates. When a column is selected the program deletes all the data and can delete an extra byte on the last line. So it will correctly delete a column of 40 comments, but for the last comment deletes one byte extra. This was not noticed by me, and as I was at that time unaware of the problem (It was unusual usage from me) and it went undetected. What this did was it deleted a bit from a binary value. So:- (as an example) h_common: ld a,d ; transfer cp e ; limit jr nz,h_move ; h_reset: ld a,(ix+#00) ; data and %000$11111 ; mask is edited by the block delete to h_common: ld a,d cp e jr nz,h_move h_reset: ld a,(ix+#00) and %000$1111 which does not look a great deal different amongst 15,000 other lines of data and code. It does however create a bug. Since I had already stated I was not updating the code for a year. It also meant I was not updating the code I had written with a fix. -------------------------------- A few days after the release I decided to undertake a revamp on the method of compression. (not explained here) The revamp on the compression method allowed more free memory to be released. The chance to change the method of play and integrate the two parts was my next challenge. So a new version was undertaken at the end of December 2021 and completed before the end of the month in 2021. Since I was not releasing an update of V1 I decided that V2 would not be released until 12 months after V1. Since it is now December 2022, the file I wrote is included here. This file should have a loading picture. I have not attached the loading picture to the game update. I include here only a .PNG image of the loading picture taken from a zx spectrum screen. ------------------------------- Mid 2022 I was casually playing with data and sprites - and wondered if I could implement a new method of drawing the sprites which would also store the data differently. Over a couple of days I implemented the new method in JSW and in MJSW. It proved the concept worked and it also released more free memory. I have spent the last 6 months with the help of Spider changing V2 and adding a lot more data and graphics. The new version is known as V3. V3 is probably more in keeping with what I had originally planned on doing. V3 will be released Next year (probably Jan 1st 2023) Note - game wise V3 is only modified slightly from v2 - 4 more rooms and slight edits in some rooms- This was not meant to change the game play. The scope of the changes was adding graphics and making the transistions between screens more flowing. These versions contain both Manic Miner and Jet Set Willy. V3 contains more graphics than either of the original game versions. So the Manic Miner part of MJSW has all the necessary graphics of the original version. In a similar way the JSW part of MJSW has more graphics than the original JSW. In fact the JSW title screen has far more variaties than the same JSW title screen, and yet both the games of JSW and MM and comapcted to fit into the 48k of the original games. ------------------------------ Due to circumstances - this is my next to last game file post and the posting of V3 will be my last. ADDENDUM - I have found the original .scr spectrum screen for the .png picture. So I will add on here the .scr picture - should be attached to the start of the file and displayed as the primary loading screen. MJSw_v2.tap MSJS_PIC.scr

The 147 rooms (in 48k) for jsw2+

Contended memory stretches timing cycles. It has a big impact. Note this code is designed to waste time - it rotates a block of memory and then copies the block of memory to the screen. Most of the work is done by the rotate part, but be aware that if it is displayed on the screen then a large chunk of the routine that is moving data into contended memory is being hampered by the contended memory problem. The routine starts by changing the border colour (at the top of the video screen) and when finished changes the border again (bottom of the screen). On my pc the border colour change is aligned with the bottom of the screen for both parts. The routine running in contended memory, loops and rotates 625 bytes. (border BLUE - ends when the border turns RED) The 2nd routine running in uncontended memory, loops and rotates 625+88=713 bytes E.G it loops 713 times (Border MAGENTA, ends on GREEN) The timing of both routines is near enough exactly the same. Yet one has managed 625 loops and the other 713 loops. The difference is very measuarable. org #7fA0 amount equ 625 high_amount equ 625+88 low_s equ #7000 high_s equ #9000 start: LD HL,#4000 LD (HL),0 LD DE,#4001 LD BC,192*32 ldir ld bc,24*32-1 ld (hl),7 LDIR ld sp,#ffff part1 ld hl,low_s ld bc,amount ld a,1 call init loopy push bc halt ld a,1 out (254),a ;<<<< set the border BLUE ld bc,amount ld hl,low_s push hl push bc loop rlc (hl) inc hl dec bc ld a,b or c jr nz,loop pop bc ld de,#4000 pop hl ldir ld a,2 out (254),a ; Set the border RED pop bc djnz loopy jp part2 init ld e,l ld d,h inc de ld (hl),a ldir ret org #8000 part2: ld hl,high_s ld bc,high_amount ld a,254 call init high_loopy: push bc halt ld a,3 out (254),a ; set the border MAGENTA ld bc,high_amount ld hl,high_s push hl push bc high_loop: rlc (hl) inc hl dec bc ld a,b or c jr nz,high_loop pop bc ld de,#4000 pop hl ldir ld a,4 out (254),a ; set the border GREEN pop bc djnz high_loopy jp part1 end start Contended memory the upper border is BLUE, when the routine finishes it turns RED Uncontended memory the upper border is MAGENTA when the routine finishes the border turns GREEN The 2nd file - sets the loop counter to be the same (in contended and uncontended) (e.g. it loops 625 times in contended and loops 625 times in uncontended) , the amount of time saved is shown by the movement of the border change. CONTEN~1.tap Contend_same amount.tap

Jumping arc of travel. It is noticable that when Willy does his sumersault jump, that one frame after the rotation part of the sumersault. Seems to be out of sync. This gives the visual feedback of pausing animation and moving horizontal mid jump. Crude picture to try and explain better. (moving from left to right)

An ommision from the above. The CPC does not have a version of JET SET WILLY2. It has a version that is identical but is called JET SET WILLY - the final frontier. Yet the cpc also contains a version called simply JET SET WILLY. Which might seem confusing, but in a way it does make sense to have the two versions. Whilst converting the game from the CPC to the Zx spectrum, I was asked was it possible to reduce the game (on the cpc) back to the original with a mere 60 rooms, eg delete 70+ rooms and leave just the 60 . I answerd it was not a big task, to reduce the size down to less than half. But did question "for what purpose?". The answer was simply to enable the game to be part of they "sold a million" compilation tapes, and strictly speaking the version I had written was not the original jet set willy, it had been more than doubled in size. Plus the smaller (a mere 60 rooms) version was not going to be sold as a stand alone product. But only on a compilation tape, which meant that both versions could still be sold on the cpc. Version 1) JET SET WILLY - the final frontier-- 130+ rooms - written first and sold first on the cpc Version2) JET SET WILLY a mere 60 rooms - sold only on a compilation tape/disc with they SOLD A MILLION compilation. (Beach head, Sabre Wulf,Jet Set Willy, Daley Thompsom-DECATHLON) The reduction down to the mere 60 rooms of the original was not that difficult. It was just a case of deleting most of the data. I added a high score table to give immediate feedback to the player that it was a different version. But their are visual changes on the title screen as well. (see picture) And before anyone says that the tail on the title screen looks like a two. It was just a copy of the squiggle on the graffiti. Which on reflection when doing JSW2, I decided to remove.

If only bright was used, then usage was technical. However I do not like the Mud versions of the bright colours. Given a choice I tend to use bright. Basic background on JSW on the CPC 464. When tasked with writing the CPC464 version of JSW, I started with the knowledge that Manic Miner on the CPC managed to use all the memory available. So JSW has triple the amount of rooms and that was why I decided to compress everything I could think of. The final version called "JSW the final frontier" was supposed to be just my version of JSW on the cpc. It was never intended to be a new version. In fact most things were toned down to stop it diverging too much from the original. When I was asked if it could be rewritten back on the spectrum, I tentatively said "probably yes". I knew it would not be an easy task. The reason behind the apprehension was because the way the cpc was doing collision detection was based on colour, but was also being drawn directly on the cpc's screen. The spectrum would need to do things differently, and somewhere along the line I would be forced to introduce a copy screen. The cpc version used translation colour bytes for the rooms. Most code was an adaptation of the cpc code. The compacted code needed to be even more compacted due to needing to save 4k when moving from the cpc game onto the zx spectrum. All screen draws on the cpc are done on the viewed screen. To stop flicker the drawing on the zx spectrum is done on a copy screen. (that takes a minimum of 4k) In essence if space was available anywhere then it was used. Most of the games running variable data is stored on the screen for the zx spectrum version The cpc version on Manic Miner with written On a Tandy Model 4 - with floopy discs The Cpc version of "Jet Set Willy the final frontier was written on a Tandy Model 4- with floopy discs The cpc version of "Jet Set Willy" was written on a Tandy Model 4 - with floppy discs The spectrum version of "Jet Set Willy 2" the final frontier was written on a Tandy Model 4 - with a 20 meg hard drive The Tandy was running Newdos 80 (disc operating system). The assembler was EDAS by misosys. Download from Tandy to CPC was done using a z80 dart. Download from Tandy to zx spectrum was done using a parallel interface - using my own direct download software - taking the Tandy's loading structure as it basis. Which allowed direct disc to memory transfer. Which was nothing like Matthews fixed memory transfer. Where source and destination occupied the same address. I will elaborate on the transfer. In Matthews case to transfer from the Tandy to the spectrum. Data is loaded into the Tandy's memory. That data is transferred byte for byte from a location on the Tandy to the same location on the spectrum. - this lead to bugs. My method interrogated the Tandy's disc loading system, and transfers the disc contents from the Tandy to the address it was assembled at. This meant a re-org of the assembled program, would also be transferred to the new org. No data (apart from one sector) is loaded from the Tandy's disc, when transferring code. Matthews method also introduced the loss of four rooms into JSW. What Matthew had not realised, was that the upper memory of the Tandy was dedicated/allocated just for the Hard disc operating system. The hard disc was bought after development of Manic Miner. So the very upper memory on the Tandy was and could be used, whilst he was writing Manic Miner. That same memory was occupied when it came to develop Jet Set Willy. Simply because he had bought himself that 5 meg hard drive. (I am surprised he did not notice) The upper memory rooms ended up being corrupted and those rooms, were eventually deleted. The upper memory of JSW still contains the TANDy hard drive code, (instead of room data) The biggest problem (apart from disc size) was the source code needed to be continually stripped of comments and meaningful labels. After a while you get used to seeing what look like meaningless labels. So a label like "main_control_loop" (which can not be written - max eight letters), gets shortened to "MCL". and slowly you get multiple versions such as MCLx,MCLp When I first saw the assembly listing again, a few years ago, it was strange to read a label such as "IAOAL" and immediately say to myself "I am on a lift" It was if I had written the label a few moments before I had read it. Yet the time gap was nearly 30 years.

To clear up any confusion on JSW2. yes I wrote JSW2,JSW2+

I must be getting old. When I wrote JSW2 I do not remember calling one room "bacon rashers and corn cob"

Number 1 is bacon rashers and corn cob.

The Thomas the tank engine graphic is from the Perils of Willy. Which at that time was a VIc 20 only game The 2nd picture shows about a 1/3 of what I disposed off (in magazines alone)- there are six stacks of magazines in this photo.

This is 100% Roger Tissyman. As is evident by the mouse, the boots and the games depicted + the SP logo

At present I am dumping tons and tons of magazines, disc,tapes, games. Most have already gone. Today I uncovered this. Nearly went in a skip. The doodle was by my daughter some time in the very distant past. At least she drew on the back

E-bay seems to have been cleared out - due to previous legal threats however https://www.redbubble.com/shop/manic+miner+t-shirts seems to supply whatever you want. - This is not an endorsement by me - I have never used this company.

I found the above (spoiler) fine in Opera, edge, Chrome,Firefox 100.0.2, opera Gx, Ccleaner browser And can also confirm the Captcha works for all of the above.

For consistancy of timing states and logic flow, it is probably better to manipulate the bits into the appropiate position. The code I listed is manipulating bits to provide an answer, but the direct route is just as quick, but varies in timing depending on the path taken. (as listed above) . L935E ld hl,rope_status bit 7,(hl) jr z,L93xx inc (hl) RES ropebit,(IX+rope0B) JR next_entity_draw L93xx BIT ropebit,(IX+rope0B) JR Z,next_entity_draw LD A,(willy_dir) BIT 1,A JR Z,next_entity_draw cpl ; in revision this is not needed rrca xor (ix+rope01) rlca ; in the revision the bit position is not shifted rlca AND #02 ; no need to isolate bit - a direct test is done DEC A ADD A,(HL) LD (HL),A NOP NOP NOP NOP NOP revised: L935E ld hl,rope_status bit 7,(hl) jr z,L93xx inc (hl) RES ropebit,(IX+rope0B) JR next_entity_draw L93xx BIT ropebit,(IX+rope0B) JR Z,next_entity_draw LD A,(willy_dir) BIT 1,A JR Z,next_entity_draw ; rrca ; move bit [0] to bit [7] xor (ix+rope01) ; bit [7] inc (hl) ; do a +1 change on rope_status bit 7,a ; check the bit[7] status jr z,skip_o ; branch if ok with +1 dec (hl) ; else revise the +1 to 0 dec (hl) ; and revise again to -1 skip_o: NOP NOP NOP NOP NOP NOP which removes the need to CPL the byte for testing and is also one byte shorter.

This is not something new. It is the above code written differently, and it still leaves those 2 bytes alone (the relative jump to the next byte - which is redundant code at #93b1) ;Now that the entire rope has been drawn, deal with Willy's movement along it. L935E ld hl,rope_status bit 7,(hl) ; ; Has Willy recently jumped off the rope or dropped off the bottom of it (A>=0xF0)? jr z,L93xx ; ; Jump if not inc (hl) ; ; Update the rope status indicator at L85D6 RES ropebit,(IX+rope0B) ; ; Signal: Willy is not on the rope JR next_entity_draw ; ;#93b3 Jump to consider the next entity L93xx BIT ropebit,(IX+rope0B) ; ; ropebit=0, Is Willy on the rope? JR Z,next_entity_draw ; ; #93b3 If not, jump to consider the next entity LD A,(willy_dir) ; ; Pick up Willy's direction and movement flags from L85D0 BIT 1,A ; ; Is Willy trying to move up or down the rope? JR Z,next_entity_draw ; ;#93b3 cpl ; ; invert the bits - only intetest is in bit [0] the direction Willy wants to move rrca ; ; shift bit [0] > bit [7] xor (ix+rope01) ; ; direction of swing in bit [7] rlca ; ; from [7] to [0] rlca ; ; from [0] to [1] AND #02 ; ; value is now 0 or 2 DEC A ; ; value is now -1 or 1 ADD A,(HL) ; ; add on the rope status LD (HL),A ; ; and save the new value nop ; ; a bit of space saved 5 bytes nop nop nop nop L938a:

JSW and MM - walking on a conveyor. Part 2:- Your past, influences your future Jsw and MM on the zx spectrum both use a lookup table for translating joystick/ keyboard actions into a new key press action. The predefined actions for every combination of key press is contained in those lookup tables. With some responses being the supposed quirks in game play. One action that might not be recognised is the response to an action when two horizontal actions are asked for. Normally the player only asks for a response for moving in one direction. Which is how most of the game is played. The player presses a direction key and Willy responds by moving in that direction. But suppose Willy is asked to walk both left and right at the same time? The action for that situation is contained in the keyboard translation / response table, and that action is to respond only on the previous key pressed, and ignore the new key. To see what this means walk to the right of the bathroom and press the key to move left. Whilst holding down left and walking left, press the right key. The movement lookup table will ignore the new key being introduced into his movement and Willy will continue walking left. Whilst walking left no matter how long or short the right key is pressed, its actions will be ignored, until the left key is released. Jumping and falling introduce more variables, but walking and holding a key down will continue on that walk until the key is released. Willy can of course walk over a conveyor whilst holding down the key. The conveyor will press the direction key for the conveyor, and the game engine via the lookup table will ignore any change in horizontal movement. Back to jumping onto conveyors. The most important point about the movement lookup table is that new horizontal actions are defined by the old actions. hence "Your past, influences your future" . The actions that a conveyor has is defined by the actions undertaken to arrive on the conveyor. If your previous action had a horizontal movement as a component of its action and that action is still being requested, then the movement table will oblige and continue with that horizontal movement. Which is why I tried to explain the consequence of falling onto a conveyor. Because when the horizontal movement of Willy is stopped (previous action) the new action (the conveyor) tries to takes over the horizontal movement of Willy. (see stopped on a conveyor :- at the end) In the situations of Willy landing with a horizontal movement component still being his last horizontal movement action. If requested to continue with the horizontal movement. (e.g. you are still pressing the key) then the conveyor action will be ignored. Stopped on a conveyor. The movement action table also explains why you can stop on a conveyor. If your previous horizontal action was no movement (e.g. a fall) then a request to move in the opposite direction of the conveyor. Will upon landing on that conveyor, result in no movement. This situation is a request to move horizontally both left and right, from a previous null horizontal movement.. That request is translated as a new null horizontal movement reponse. These actions are all defined in the movement lookup table.

JSW and MM - walking on a conveyor. Part 1:- When Willy is jumping he can have a forward movement component for the arc of travel.. Which is basically an automatic key press in the direction he is jumping. When the arc of the jump is finished, and he starts falling, the code kills his movement key and willy no longer has a horizontal movement component for his actions. This means at the point of landing on a conveyor from any fall, (note I say fall- and not jump) Willy can NOT have a horizontal movement component and this coupled with the automatic key press supplied by the conveyor results in the actions as seen. All other instances of landing on a conveyor that is level or above the start point have the horizontal component still intact from the start of the jump, and this is transfered to the point of landing. Nothing strange or convoluted in this coding of action.

Taking the actual code used to control Willy on the rope . It took me all of 1 second to change the logic. This original is deliberate and very logical in the manor of control. Walking up a stair you press against the stair, to move down a rope you press against the rope. Which to me is reverse logic, but still a consistant logic. To modify to play as you mentioned is the lazy way of coding the movement and not the other way around. Note the ease of modification Part of the rope swing LD A,(willy_dir) ; #9375 ;#85D0 Pick up Willy's direction and movement flags from #85D0 BIT 1,A ; #9378 ; Is Willy moving up or down the rope? JR Z,next_entity_draw ; #937A ;#93b3 If not, jump to consider the next entity ;CHANGE CODE FROM ; RRCA ; #937C ; XOR Willy's direction bit (0=facing right, 1=facing left) with the rope's direction bit ;; ;; ; (0=swinging right to left, 1=swinging left to right) ; XOR (IX+rope00) ; #937D ; ; RLCA ; #9380 ; ; RLCA ; #9381 ; Now A=1 if Willy is facing the same direction as the rope is swinging (he will move down the rope), ;; ;; ; or -1 otherwise (he will move up the rope) ; CHANGE CODE TO RLCA ; #937C NOP ; #937D NOP ; #937E NOP ; #937F NOP ; #9380 NOP ; #9381 ;>> back to the normal logic AND #02 ; 9382 ; DEC A ; 9384 ; included is a file with the rope swinging in such a way. NOTE this file is so close to the original --- it might still have the attic bug --- I can not remember. Addendum:- easier is to just zero out #937c, #937d, #937e, #937f, #9380. -- five 0(zero) pokes. jsw rope swing.tap

Correction on the misinformation about automatic room switching: JSW can switch rooms at around 4 frames per second. The graphics will appear on the screen. long enough, for the room to be recognised. Additionally you will be able to follow what willy does. This means the minimum time MUST be around 15 seconds, and that time is to just flash through 60 rooms. That time however does not allow much leeway for moving around the rooms.

The rope is very simple in operation. Matthews code does its best to obscure that simplicity. The rope data has offsets for x and y. - the data below is padded out to 256 bytes rope_table_X: DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H01,&H01,&H01,&H01,&H01,&H01,&H01,&H01 DATA &H01,&H01,&H01,&H01,&H02,&H02,&H02,&H02 DATA &H02,&H02,&H02,&H02,&H02,&H02,&H02,&H02 DATA &H02,&H02,&H02,&H02,&H02,&H02,&H02,&H02 DATA &H02,&H02,&H01,&H02,&H02,&H01,&H01,&H02 DATA &H01,&H01,&H02,&H02,&H03,&H02,&H03,&H02 DATA &H03,&H03,&H03,&H03,&H03,&H03 ;================== DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00 ' y-coordinate shift rope_table_Y: DATA &H06,&H06,&H06,&H06,&H06,&H06,&H06,&H06 DATA &H06,&H06,&H06,&H06,&H06,&H06,&H06,&H06 DATA &H06,&H06,&H06,&H06,&H06,&H06,&H06,&H06 DATA &H06,&H06,&H06,&H06,&H06,&H06,&H06,&H06 DATA &H06,&H06,&H06,&H06,&H06,&H06,&H06,&H06 DATA &H06,&H06,&H06,&H06,&H06,&H06,&H06,&H06 DATA &H04,&H06,&H06,&H04,&H06,&H04,&H06,&H04 DATA &H06,&H04,&H04,&H04,&H06,&H04,&H04,&H04 DATA &H04,&H04,&H04,&H04,&H04,&H04,&H04,&H04 DATA &H04,&H04,&H04,&H04,&H04,&H04,&H04,&H04 DATA &H04,&H04,&H04,&H04,&H04,&H04 ;=========== DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00 simple logic for animation A pointer is set as an offset into the data (as above) The pointer has two other variables - side and step The step is added to the offset. if the offset is now 0 then reverse the step and reverse the side - simply negate the side and step. if the offset is maximum the reverse the step- Simply negate the step The above is the core logic for animation -------------------------- To draw- start x=128; start y=0: loop draw point x,y Take the offset into the above data - find the x entry - delta x- and if side is 1 add delta x to x ; if side is -1 deduct delta x from x Take the offset into the above data : find the y entry and add to the y add 1 to the offset loop for the length of the rope the above will need adjustments, with the size of steps and length of rope etc =but will draw the rope.

Assuming you can draw the rope. Starting at the top we count the pixels drawn for the rope draw. If Not attached to the rope. Each cell drawn is tested for collision. if collision then willy is attached to the rope at that point. If attached to the rope. The cell that is assigned as the collision point (as above) is used as the x,y position to draw Willy - (slight shift adjustment needed in zx spectrum code) To move on the rope the point of collision is moved up or down the rope To detach from the rope. A timer is set and Willy is cell aligned and exits from the rope.

In zx spectrum JSw and JSW2 and JSW2+. When Willy is walking along he is always aligned to a character cell. When Willy is above a ramp/stair he is still aligned to a character cell, but is drawn with a displacement. When Willy appears to walk diagonally up or down a stair. He actually walks in steps of one char up and down the stairs. It is the displacement code the makes him appear to walk diagonally.

I will again state. It is possible to run Manic miner and return to basic. On returning to basic it will still be possible to poke the game and again enter MM ( and if needed keep on repeating the loop of running the game and returning to basic). All the basic that was in memory before running MM will still be there. Because certain members on here do not have the skill needed to do this does not preclude others from doing so. (e.g. I can if I wanted, do the modifications needed. But I have no intention of doing so. ) in the 30+ years since MM was written I have had no need to do so, and I still have no need to do so.

Clarification on those pokes The POKE to set the starting room to Room r is 34795,r. (is for JSW) POKE 33824,r is a useful runtime POKE to teleport to Room r. (is for JSW)