Norman Sword

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.

Tools used for writing Manic Panic Context (text editor for writing the assembler code) Pasmo (A z80 assembler) Fuse (for testing assembled code) QBasic for tedious calculations. Code was written as needed - no usage of libraries. No usage of other programs - apart from those listed above. All additional graphics were typed in binary. Music data and music code directly typed in. Room layout data (platform positions)- typed in directly in hex. Sprite movement and room specific data - typed out by hand. Sprite movement - mentally calculated and typed in. Room graphic tile data (numeric data was visually taken from another program I wrote MANIC 40 MINER and then typed in. I allowed macro's to transpose the data. The main code block is 9,155 lines of comments, equates and code. which is 450k in size The sprite file is 1,480 lines of hex statements and binary statements. which is 41k in size The room data is 3,450 lines of macro's and data statements. which is 128k in size Every time I changed the program logic and needed different data - I edited the above files with a text editor.

Willy having a directional beam of light. A topic I have known about for many many years. Which was not a new idea for me, so- Sorry to disappoint you, but the original code and idea was mooted for Jet Set Willy 2. The room with the trip switch was designed to switch off the lights and implement a circle of light. The circle of light code was written, but took too long to implement as a game feature. I'll expand on that - Derrick P Rowson had written a graphic routine to illuminate a circle of light. If the code had been implemented on the spectrum first the circle of light would have been implemented. Alas the original version was on a CPC 464 and the speed of processing was not fast enough.

View File Manic Panic Manic Panic. Plays on ZX Spectrum and similar hardware. Runs and plays in48K This game could have been written when the originals of Manic Miner, Jet Set Willy and Jet set Willy 2 was written. It does not need the memory or hardware of the expanded versions of the ZX spectrum. very very brief note:- The original plan was to create a full sized playing screen game. An upgrade on the 2/3 screen playing area of MM and JSW. I decided to continue the story of Miner Willy. Willy Started out exploring in Manic Miner, and hit the jackpot. He then splashed out his monies on a new mansion which was explored in Jet set Willy 1/2 and 2+. In the present day his memory of the past is playing tricks on his mind. Did he switch any of the robots off in Manic Miner? In Manic Panic I leave you to find out. What he does next Whilst the basic code was easy enough to write, I did encounter problems with breakup on one part of the screen. This problem nearly caused me to to cease writing and scrap the idea. I persevered and after two weeks I had most of the basic code. The game has multiple playing modes 0) Trainer, 1) Normal, 2) Expert, 3) Ace , 4) Lantern, 5) Torch. Each mode differs from the others modes in a specific way. Outline, based on how I remember the code. Modes 0) Trainer -- Full oxygen ---- Slow oxygen depletion ------ Oxygen depletes on contact - (-2) sprites - No final Bonus - No end game 1) Normal --- Metered oxygen - Normal oxygen depletion ---- Oxygen depletes on contact - (-1) sprite -- Final Bonus ---- End game ----- enables ace mode 2) Expert --- Metered oxygen - Faster oxygen depletion ---- No contact allowed (death) - all sprites -- Final Bonus ---- End game ----- enables ace mode 3) Ace ------ Metered oxygen - Very fast oxygen depletion - No contact allowed (death) - all sprites -- Final Bonus ---- End game ----- playable only if another mode was completed. Extended modes - added as a novelty 4) Lantern -- Metered oxygen - Normal oxygen depletion ---- Oxygen depletes on contact - (-1) sprite -- Final Bonus ---- End game ----- enables ace mode 5) Torch ---- Metered oxygen - Faster oxygen depletion ---- No contact allowed (death) - all sprites -- Final Bonus ---- End game ----- enables ace mode -- oxygen depletion stops if static. The extended modes adds a lot of code. And are based on the idea that the caverns are dark and are illuminated by Willy in two ways. In lantern mode the cavern is completely Blued out. Willy can use the light that is attached to his helmet and illuminate the cavern. The light will point in the direction of Willies travels. If Willy is walking Right the the beam of light from Willies helmet will also shine to the right. Conversely for the left. When Willy is static and is not moving horizontally Willy can rotate the beam of light in either direction. The keys for rotating the beam of light are the keys "H","J","K","L" - with "H" and "K" rotating in one direction and "J","L" rotating in the other direction. The rotation keys have inbuilt delays (similar to keyboard delays). The items are set to still colour cycle or animate in the blued out room , so their positions are always visible. The portal is also still visible. The above (lantern) was extended into another version. The Torch version. Here the room is blacked out, which makes the surrounding platforms disappear. In order to facilitate playing in such a room, and not make it pure guesswork or committed to memory in order to play. A small area around willy is Blued out, this area shows the platform willy is standing on. The steady depletion of oxygen is stopped, whenever Willy is static (stopped) and the rotation of the torch beam can be undertaken to illuminate other parts of the screen. To further facilitate travelling around the screen, all items/objects/keys collected will briefly flash and illuminate the room when they are collected. I have played every cavern in Lantern and in torch mode, whilst it can add a layer of difficulty to each cavern. The fact I have completed them shows me they can be completed. The screens have not been memorised by me and since they are all relatively new, I play them with only a limited memory of how to play them each time I see them. Changes from MM/JSW This list just touches on some aspects of code change. I rewrote everything- some with better design than others. Full screen playing area - an increase of nearly 50% Willy now has a sprite mask. All sprites can move in any direction. Room events are changed to sprite events. E.g. Kong is a sprite and not a cavern that has Kong in it. Sprite events can be mixed. e.g. Kong- Skylab - light beams etc can all exist in any cavern. Sprite events specify their own graphics. e.g. you can have differing graphics on the Skylab graphic event in the same room. Sprites can cross other sprites - without killing Willy. Sprites can cross graphics in the background without killing Willy. every sprite can define its own graphic. Sprites can be 16, 8 or 4 pixels high. Addition of worm collision sprites. Addition of time phased dropping sprites. Addition of animated items/keys. Colour cycling on items/keys cycles correctly in 7 cycles and does not repeat in cycles of eight with duplicate colours. Keys/items can animate in 1 phase, 2 phase, 4 phases. Cavern graphics allow up to 16 differing graphics per room. Cavern graphics incorporate a new style of tile - being an invisible/ignore tile. Graphics such as the nasty graphics are during game cycle allowed to act as nasties and also be ignored. -- reason for ignore tiles -- In JSW/MM - Willy can stand on any tile -- These tiles need to be ignored due to being able to survive nasty contact. Graphics do not suffer the duplication of colours bug that plague the differing versions of JSW and MM. Possible to have two differing tiles and one colour. Multiple on screen Conveyors can be animated in different places. Conveyors can have both left and right conveyors in the same cavern. Special code added to allow Willy to straddle two conveyors and not lock the movement keys out. Air bar is depleted in a progressive manor. Depletion when full is slow. When nearly empty depletion is fast. Rate of depletion is based on the height of the oxygen. The change in speed of depletion is constantly changing. Air bar depletion is also changed by the game level played. Easy levels use a slower rate of depletion compared to the harder levels of play. Dual title music playing routine Music routine play pitch corrected notes. Music routine illuminates correct keyboard keys. Music routine allows music tempo change. Music routine allows notes of differing length Music routine allows rests. Music routine can play notes from 5 octaves Multiple game playing modes 0) Trainer, 1) Normal, 2) Expert, 3) Ace , 4) Lantern, 5) Torch. Each mode differs from the others modes in a specific way. Behind the scenes a lot of added code is taking care of several aspects of space management. Since this is just a short note those aspects and the details of the changes will not be added here. Submitter Norman Sword Submitted 12/09/2020 Category Manic Miner [Remakes]