Norman Sword

The technical changes from the original file I listed. It was noticed that out of all the playable rooms. Only 6 needed data to change how the routine modified the room. So this file stores only six room numbers and the data for those 6 rooms ( and an extra one for luck- CPIR) The original query wanted a period of immunity after death. Whilst easy enough to do. It needs more code than I was prepared to write. The code is not the problem. The backward reference to the original is. After playing the modified rooms I noticed I was occasionally killed as I entered a room. The random aspect meant that I would re-enter the room and again in most cases the sprite would have been moved by the routine, and would start in another place. So respawning back in the same place was not a fatal flaw. After wandering around heaps of rooms, it became noticeable that this occasional problem was mainly the horizontal sprites. (it might happen with vertical sprites - but not on my wandering) So instead of addressing the immunity problem I instead addressed the problem of sprites being in the vicinity of room edges instead. The added code that is not in the original listing, takes the trouble of moving any sprite that is left near a room edge. This added code will move sprites away from the immediate vicinity of the left and right edge. It only moves horizontal sprites. From the wanderings I had, this small change allows in most cases the entry into a room without a problem.

Multitude of ways. I only looked at the data. And whilst looking at the data I added an extra entry. A multitude of options to correct the CPIR step dec hl change the offset to only five instead of six or just add an extra byte to the data. In every case the file grows by one byte.

The problem arose for a far more mundane reason. CPIR. I set up a search for the room number then once it was found stepped over the room numbers into the room data. So searching six items and stepping over six items to the corresponding room data. Simply forgot that the CPIR stepped past the data it matched. I just added an extra byte of data to allow for the CPIR step after a match.

A quick look at the code and I have spotted the problem. One byte short in data - I will update the file above. The code assumes that this is the original JSW and only stores the rooms that need the sprites adjusting (6 rooms). All the other rooms are assumed to be full adjustment. The code steps through the room numbers and then steps into the data. However in the original file. The step onto the room data that specifies which sprites should be moved in those 6 special rooms was stepping one byte short. So it found the room was special, but did not match the special room with the correct data for that room.

The colours are from an lcd widescreen monitor. Nothing special.~ Provided here is the final version of the random patch. This is similar to the listing I provided, but is extended in scope. Using an original JSW file - which I am not providing. ; Load JSW - ORIGINAL - RETURN TO BASIC ; load this file over JSW - a 238 byte file - code loads at 65400 ; RANDOMIZE USR 65400 - TO INSTALL PATCH ; RANDOMIZE USR 33792 - TO PLAY Not extensively tested - main purpose is to see what the game runs like when modified in such a way. This file is one byte bigger. Which shifts the room data by one byte and corrects the problem (I hope) rand_sp.tap

DSCF9962.MOV The centipede moving with a smoother path.

Yes a 256 loop when b=0 with DJNZ. The edits I do when I change the code from the original (as written in my own version) to the version that is seen above. Create more problems as I go along. I constantly change the code from the original layout, without any checking/testing. Sometimes those modification create all the subsequent edits I need to do. I think it is 99% there.

supposed to say #80e0- When I write these routines I do not have the original data. I have my own and I do not use direct memory references, I have to work backward and calculate where the original might have been. Yes it should be INC A. I will slowly correct whatever I see as being incorrect. It does however work as seen. The problems arise most of the time from having to change most of the code to fit in with the original data/layout. So I will do another edit/update and change the { inc b } to { inc a }

This has been tested and works exactly as specified. It needs the room data changing to stop the giant heads being shifted and the forgotten Abbey and the attic data being shifted- An easy enough task Half an hour to write. Somewhere near the end of the room set up a call is made to rephase_room The data at offset #e0 in every room is changed to #00 modify the sprites or #ff leave alone. Or the bits in the byte signal which sprites must be left alone. So writing 1110 0000b would instruct the routine to leave the first three sprites alone. ( eg. stop it phase shifting the big heads if they are the first 3 sprites in a room) random_sp equ #80e0 return_2_me equ #91b6 entity1 equ #8100 ; rephase a room rephase_room: ld hl,random_sp ; this address is any free byte in the room data - each room needs this setting up - most rooms can be left as zero ld a,(hl) cp #ff ret z ld c,a ; this is the entity bit move mask ;initialise the guardians ld a,#c9 ld (return_2_me),a ; modify the next sprite entry - return2 me is at address #91b6 LD IX,entity1 ; Point IX at the first byte of the first entity buffer at L8100 Phase_shift: ;test the end of sprite data then test the bit held in c; this signals a possible move LD A,(Ix+0) inc a ; cp #ff jr z,no_more bit 7,c jr nz,a_static cALL RANDOM AND 127 INC A ; instead of INC B LD B,A SHIFT_IT PUSH BC CALL L90C4 ; MOVE THE SPRITE POP BC DJNZ SHIFT_IT a_static ld de,8 add ix,de rlc c jr Phase_shift ; ensure it is put back no_more ld a,#11 ;ld de,# ld (return_2_me),a ret ; the RANDOM routine does not produce RANDOM numbers it produces a sequence of numbers that is fixed in sequence. The number of digits in the sequence is large before it repeats. At machine speed calling random will produce a pattern based on its output. RANDOM: PUSH HL S_M_C_address equ $+1 LD HL,$-$ S_M_C_SEED equ $+1 LD A,$-$ xor (HL) XOR L XOR H inc hl res 5,h LD (S_M_C_address),HL LD (S_M_C_SEED),A POP HL RET ; *** NOTE *** only 6 rooms have a value that is not 0 (zero) - 7,20,28,39,42,48 ---- rooms value start at 1 in this list ; values for byte #e0 ;"The Off Licence" 1 db #00 ;"The Bridge" 2 db #00 ;"Under the MegaTree" 3 db #00 ;"At the Foot of the MegaTree" 4 db #00 ;"The Drive" 5 db #00 ;"The Security Guard" 6 db #00 ;"Entrance to Hades" 7 db 11100000b ;<<<<<<<<<<<<<< ;"Cuckoo's Nest" 8 db #00 ;"Inside the MegaTrunk" 9 db #00 ;"On a Branch Over the Drive" 10 db #00 ;"The Front Door" 11 db #00 ;"The Hall" 12 db #00 ;"Tree Top" 13 db #00 ;"Out on a limb" 14 db #00 ;"Rescue Esmerelda" 15 db #00 ;"I'm sure I've seen this before.." 16 db #00 ;"We must perform a Quirkafleeg" 17 db #00 ;"Up on the Battlements" 18 db #00 ;"On the Roof" 19 db #00 ;"The Forgotten Abbey" 20 db #ff ;<<<<<<<<<<<<<<< ;"Ballroom East" 21 db #00 ;"Ballroom West" 22 db #00 "To the Kitchens Main Stairway" 23 db #00 ;"The Kitchen" 24 db #00 ;"West of Kitchen" 25 db #00 ;"Cold Store" 26 db #00 ;"East Wall Base" 27 db #00 ;"The Chapel" 28 db 11100000b ;<<<<<<<<<<<<<<< ;"First Landing" 29 db #00 ;"The Nightmare Room" 30 db #00 ;"The Banyan Tree" 31 db #00 ;"Swimming Pool" 32 db #00 ;"Halfway up the East Wall" 33 db #00 ;"The Bathroom" 34 db #00 ;"Top Landing" 35 db #00 ;"Master Bedroom" 36 db #00 ;"A bit of tree" 37 db #00 ;"Orangery" 38 db #00 ;"Priests' Hole" 39 db 11100000b ;<<<<<<<<<<<<<<< ;"Emergency Generator" 40 db #00 db Jones will never believe this" 41 db #00 ;"The Attic" 42 db #ff ;<<<<<<<<<<<<<<< ;"Under the Roof" 43 db #00 ;"Conservatory Roof" 44 db #00 ;"On top of the house" 45 db #00 ;"Under the Drive" 46 db #00 ;"Tree Root" 47 db #00 ;"[" 48 db #FF ; no sprite data ;<<<<<<<<<<<<<<< ;"Nomen Luni" 49 db #00 ;"The Wine Cellar" 50 db #00 ;"Watch Tower" 51 db #00 ;"Tool Shed" 52 db #00 "Back Stairway" 53 db #00 ;"Back Door" 54 db #00 ;"West Wing" 55 db #00 ;"West Bedroom" 56 db #00 ;"West Wing Roof" 57 db #00 ;"Above the west Bedroom" 58 db #00 ;"The Beach" 59 db #00 ;"The Yacht" 60 db #00 ;"The Bow" 61 db #00 The data followed by ;<<<<<<<<<<< is indicating values that are NOT zero

In jsw there are less than 128 entities. The entities are jiggled around and form all the sprites in JSW. When an entity is defined it defines certain parameters. The parameters it defines for a sprite that moves vertically is the upper and lower points and its vertical start position. The entity can then be moved horizontally to its start position. The centipede in the attic has an entity defined for each and every part of the centipede because it can not move the vertical start position. The routine I wrote uses the move start position (as written above) to move the fixed start position of one entity to duplicate the original multiple entities defined. So yes the statement I made was correct. I will check ---- If the above is correct.

Further elaboration on starting in a random place. When the room has been drawn and all the room data has been drawn. In jsw128VM, VK and VL a routine is called that moves the start position of designated sprites. For a working example. I will describe the sprites in the attic. In jsw128Vm they are all the same sprite. The program only stores one sprite and not the sprites that the standard JSW stores, which is one sprite entity per part of the body. For each part of the body the horizontal position is changed (as normal for a sprite) The vertical part of each sprite position is fixed. The program calls the movement routine a specific number of times for each part of the body. This repeated calling allows the start position of each part of the body to be moved a set distance from the original start position. The sprites are finally drawn when the room is drawn with all the parts having been moved from the single entities start position. This might sound like it will be slow to execute. Yet I have never witnessed a delay jumping from room to room in JSW128vm and no one has even hinted that a problem occurs in the time taken to move from room to room. These type of convoluted and extended routines are not part of the main game playing loop, The amount of processing that can be undertaken when jumping from room to room is massive. In JSW128VM the amount of room generation code is massive, but as stated it is not a problem.

Easy to randomise the sprite start positions within their paths. JSW128VM runs a similar set up. (just not obvious it does so) The major problem beside IDS and sprites starting in the entry position of a room. (which causes one death) is the paths of sprites that do overlap with each other. The monks in the forgotten Abbey will collide with each other.--- (are there other rooms?) What you have suggested is to me, very easy to do. Even adding a period of immunity is very easy to do (for me). Having said the above I have no plans to write such a game. Starting in a random place - ignoring the other aspects of the game. When the room has been generated and it normally returns to the main part of the game. Instead for each sprite call the movement routine for that sprite a random number of times.

I downloaded an emulator called MicroM8. Unzipped and ran prog. Dropped the disk file onto the window and it was running. Runs at a decent speed. I did not play for long due to the auto movement routine that is incorporated into the game. If you press and hold any movement key the game runs at a reduced speed. So to play it is press right key to move wait for the jumps and press jump. Hit wall press left key and wait for jumps. Hit wall. Press right key and jump, wait for other jumps and die ==== could not manage the return run on the top. I will not be persevering to get further.

My comment was on the fly.

Since lambs have no plumage, they will plummet,

Not something I had noticed before. But are you aware of falling Skylambs. One of the most deadly objects known to Willy. Comes down and "CHOP" Willy is dead. I am sure that the word was misheard, and knowing the nature of computer games, was not questioned.

I watched all of the JSW2+ and all of the double manic miner speed play. Very interesting to watch.

Remember that keyboard movement is not the only movement Willy makes. 1) forced movement via a conveyor 2) falling 3) jumping 4) collapsing a platform floor.

The first post mentions the inability of my pc to correctly scan the emulated spectrum keyboard. Which prompted me to write the key_test routine. That was way back in 2017. Since then I have moved through several machines and also several operating systems. My present configuration does not exhibit any problems. In 2020 I changed my pc and installed windows 10 pro. That pc was originally configured with a new keyboard that had a strange keyboard layout and also a keyboard reset button. That when pressed turned the pc off. Something that I might have reconfigured eventually. I took another path and installed a gaming pc keyboard. That keyboard when hooked up to my pc and running FUSE which is emulating a ZX spectrum, which is running Key_test4.tap. Shows my gaming pc keyboard can pass any combination of keys through to Key_test4. And when I say any, I have tested as many as 20+ keys at a time. I once spent hours reading the technical blurb on the CPC machines. Which outlined the technical reasons why the CPC does have scanning problems. In usage the real and physical zx spectrum has not given me any keyboard scanning problems. The problems only started with emulation and the convoluted passage of data from keyboard hardware to pc hardware to operating system to emulator to emulated zx hardware to zx program. Where the problem lies is "above my pay grade". But the purchase of a gaming keyboard which is designed to stop key jamming and a host of other problems would seem to indicate to me that the physical keyboard was probably the main culprit of my old problems.

Mentioning the key scanning process, prompted me to edit the "Key_test.tap" program, mentioned in the first post. Since I can see no means of editing the first post, I can not add the update there. I have graphically updated the program mentioned "Key_test.tap". I know it is only a utility written in a few hours, but I felt it could look graphically better. This is only a small graphical update. Purpose of program:- Running this program will repeatedly scan the keyboard and display the output as would be scanned by a spectrum. Some keyboards do not enable multiple key presses to be passed through the host machine and into an emulator. This program will display the keys an emulated spectrum would see. key_test4.tap

In the distant past, I too had problems with keyboard scanning. Whole groups of keys would not be responsive when playing JSW or MM and the cheat was activated. This inability to scan the keys accurately meant the cheat actions on those games could not be fully implemented. I wrote a very small program to display the results of what the host machine sees when emulating a spectrum's keyboard. That program showed me that on the computer I was using at that time. The exact problem of scanning for D-F-G was also prevalent. (my present keyboard/computer does not exhibit the same problems) The above is the primary reason I tend to not ask for multiple key presses when writing a game. Because these key options, in Manic Panic, were not an important part of the game. I was only concerned with my own ability to change those in game options. When the routine was written. To check out if your emulation of the zx spectrum is having problems, it is probably worth running the emulation test program I wrote. The program I wrote was called key_test.tap It is available to members somewhere on this forum. It's under the heading "Emulator key scanning" ------------------------------------------------------------------- The routine for drawing dust is added in a similar way to how keys are drawn. The game loop has already drawn and animated the conveyors, Willy, Sprites etc and has checked for collision. Then it adds dust, keys, portals. So collision with dust can never occur.

Merry Christmas to all.

Just as easy for me to explain those extra key presses. There are two other key combinations that change trivial game settings. If the key combinations do not work, then the option can not be changed. Both of the extra options are as stated trivial changes to the game. I added the options, simply to see which setting I prefered. The default setting is my prefered setting. Very brief ---- "A" - "S" - "D" changes the interrupts (as stated on my last post) "S" - "D" - "F" changes the way the border flashes when Item/objects are collected. "D" - "F" - "G" changes the way the way landing on a platform is displayed. (Dust) ------------------------------------- "ASD" changes interrupts - Status indicator= "H-score" - Green=interrupts on - Yellow=interrupts off "SDF" changes border flash - Status indicator =The numeric part of "SCORE 000000" - White=border flash on - Cyan=border flash off "DFG" changes foot landing (dust) - Status indicator= The numeric part of "H-SCORE 000000" - White=dust displayed - Cyan= No dust displayed ------------------------------------- The border flash was added simply because I tend to play without the sound turned on. When playing "Water Permeation" the item/objects turn themselves on and off at regular intervals. It is possible to jump at an item/object that is displayed and at the moment of collection the item/object could switch off. When playing with no sound there is no real feedback as to whether the item was collected or it switched off. The border flash was added just for this room. If playing with sound, probably no reason to have the flash enabled. The combination "SDF" will turn the flash on/off/on etc. ------------------------------------- The foot dust routine was added over a period of an hour. The switch option was added so I could see which mode I prefered. It was left as being on by default ------------------------------------ If the above options can not be switched by the relevant key combinations you are not missing much. They were written basically for me to change at will what the game displayed. I consider the three sets of key switches a trivial addition - they are not intended game features. ---------------------------------- Trivia:- The end game sequence where it says "PLAYING VICTORY TUNE" and the sequence of border flashes, is another consequence of me playing with no sound. Without that feedback text and border flash, it looks like the game has crashed.

The purpose of those keypress combinations was to enable raster interrupts. I constantly experiment and one of those experiments was the enabling of interrupts. The purpose of enabling interrupts was to stop the jitter caused by framing rates being inconsistent. (I can expand on why that causes jitter, and what is the actual cause of the change in framing rate) - but not here Enabling interrupts allows for more consistent frame time, which helps stop jitter. It does however as a trade off, slow the game down. The amount of slowing down will vary and whilst it does slow the game down. The amount is based on rounding up frame times and will not produce a slowed down game as such. Some caverns could run at nearly the same speed whilst others are slowed down quite a bit. Since its purpose is NOT to enable a slower game but to stop jitter with a side effect of possibly slowing the game down in some caverns. Knowing how to switch the effect on will not really help if the objective is to run the game slower. The title is Manic Panic - a game that runs fast, and plays fast. Willy Lethargic can be achieved by changing the speed of most emulators to play at what ever speed is needed. The above mentions why I added the ability to enable interrupts. And why I prefer the game to be left at full speed. However I added the ability to enable interrupts because of MY concern over jitter. And for that reason alone, I will divulge the key press needed to enable interrupts just to show that the judder/jitter that the game experiences can be removed if needed. Whilst playing:- Press "A" "S" "D" all together - the game will enter pause and display the status line. (doing this action will also change the status of the interrupts) The colour of "H-Score" indicates the status of Interrupts - Green indicates Interrupts are enabled and the game might run slower with no jitter/judder Yellow indicates interrupts are turned off and the game runs flat out with slight jitter/judder Exit back to the game with any key that exits from pause. Interrupts can be turned on and off at any time and in any room/cavern. Repressing "A" "S" "D" whilst in pause will toggle Interrupts on/off/on etc

Anyone following the heading Post of "MANIC PANIC" would after around 16 posts, find the theme has been hijacked into a discussion on Christmas and JSWED . JSWED is a program I do not use. A program that does not enable anyone to edit anything written by me (Norman Sword) - Altered Reality - Manic Panic - Manic 40 Miner - Dual (SP and BB) Manic Miner etc The hiatus in the theme would probably curtail the casual reader from continuing if their only interest was Manic Panic, and for that reason I will not add anymore detail about Manic Panic here. If any more detail is needed it will probably be easier to edit one of my posts the occur before post 16 and add any detail there. (before the major sidetrack) Concerning Downloads:- Great to pass 350 downloads, which are of course FREE.