Norman Sword

Assembles and runs on Brave / Firefox / chrome / edge /opera.

I have deleted every other version up to V6c6. The version chronology was v,v1,v2,v3 etc small updates in code V3,v3a,v3b etc. Updates only in data. V6c,V6c1,V6c2,V6c3 etc.

A more extensive scope/explanation of why I wrote the keyboard scanning program. When emulating the zx spectrum, it can sometimes not respond to certain keyboard key combinations. When I was writing various utilities and even playing games on the zx spectrum. I was constantly aware of key combinations that did not seem to work. The cheat combinations of JSW and Manic Miner are a good example of key combinations that on various emulators and various pc's. Seemed to not respond correctly. The problem varied between my various pc's and changed according to the keyboard used. The problem was big enough for me to investigate what the emulator on my pc was showing as a key press. If I am writing a routine that needs key presses then having an emulated pc that can not respond to those key presses becomes a big problem. For example Manic Panic uses "ASD" "SDF" and "DFG" as groups of keys that have an action that changes the game play. Those key combinations work on my pc. Yet IRF has stated they do not work on his PC. To find out what my PC says is being pressed as a key and passed through its hardware/software to an emulator etc I wrote the keyboard scanner. Running the keyboard scanner, does a constant key scan of every key on the spectrums keyboad and displays which keys are being pressed. This should show clearly any key combination. The spectrums hardware and the emulated spectrums hardware should not have any problems responding to any key pressed. The keys pressed will show up on the simulated spectrum keyboard. When I originally wrote the keyboard scanner, I was suprised to find that certain groups of keys would not respond, when more and more keys were pressed. Most of my keyboards attached to most of my Pc,s had one problem or another. They were fine with one or two keys but failed as the keycount increased. I changed my code to remove key combinations that did not work. As stated earlier the most commen multiple key press combination program I used was JSW and Manic Miner. Both of these programs failed the multi keypress test. Running my keyboard scanner showed the scope of the problem and which key combination did not work. It will be noted that every re-write of JSW and Manic Miner I have done. Does NOT use the multi keypress type cheat that is in the originals, mainly beacuse of the keyboard problem. ----------------------- I mentioned elsewhere (another post) that I had a keyboard that was configured with a reset on the keyboard. To overcome accidently pressing the keyboard reset, I bought a gaming PC keyboard. ----------------------- Every problem I used to experience with scanning multiple key presses on an emulated spectum disappeared. Running my keyboard scanning program showed that the problems of groups of keys, seemingly stopping the response of other keys on my emulated spectrum where gone. I can now press any combination of keys and they will all show up on my keyboard scanning program. ---------------------- Concerning Mr top Hat Running on an emulated machine. The problems described by your inability to press the combinations of keys in an emulated spectrum game. Are more than likely, the problem of your keyboard. Running the keyboard scanner will remove the game from the test loop and focus only on what the emulator is seeing. If the keyboard scanner I wrote allows those combinations of keys to be pressed then the problem is the game. If it does not show those combinations of keys being pressed then it is the keyboard you are using.

Did you try running the simple program I wrote, it will display keyboard scanning problems very clearly? Downloaded the game (Mr Top Hat) and pressed the cheat key combinations. Emulated on fuse. Off to bed - its 4.35am

Its 4am As they say "a picture is worth a thousand words" Just looking at the nice green and black wall, and the nice green and black bush(that is deadly to the touch). MMMMmmmm ... The wall is/was defined as a nasty, which is obvious when looking at it knowing it kills on touch. Very suprised it was not noticed earlier. Wall colour (part of the the part erased) colour changed. Final version - which can be played through all 40 caverns. Instructions and re listed in the first post Manic 40 Miner V6c6.tap

I was looking for information on a totally different matter. When I spotted this. It runs on a PC. From YorkshireKev. I have only briefly looked at the program. Its different ... central-cavern-windows.zip

Jetsetdanny said:- However, I don't know if it is possible to enter the long Writetyper codes for these rooms [654219 and 65439, respectively] on emulated keyboards (it's not possible in Spectaculator, as far as I can tell), and I don't have any way of checking it on the real hardware right now or in the foreseeable future. Hence, in the picture gallery I included these rooms as ones which can "probably be accessed by using the Writetyper cheat". If anyone should be able to verify this, I would be happy to correct the information on JSW Central. My response:- Problems scanning keys. Running my program https://jswmm.co.uk/applications/core/interface/file/attachment.php?id=7279 Shows I can (with my gaming keyboard - on fuse) hold any of the above key combinations. The difficulty being I can't hold the first (654219) set of keys and navigate the mouse to do a screen shot. I can with the smaller combination 65439.

Just walk off the platform. Just to the right and below the platform in question. Is a collapsing floor. Knowing it will collapse as you walk on it means that the initial jump upwards (at the beginning of the cavern) onto the collapsing floor. Must be followed by a right jump shortly after landing. This leaves enough remaining, to enable you to walk right from the problem platform.

Changing data =========== Changing conveyor directions - in some cases this also involved changing the graphic and the colours. The data for item/objects/keys was not copied from the original. (as is evident) Changes for V6c5 28 -- United... changed conveyor direction also added an item/object/key upper right. 29 -- germo... changed conveyor direction 31 -- Finding... moved item/object/key one block left 32 -- The Pronc... The switches, and their action. The switches are scanned on building a room. If the room if filled with switches, only the first two are active starting at the top left and moving right and down. For the purpose of completing this cavern and removing the confusion, the extra switch has been deleted. The problems with positions of item/object/keys. I have moved item/object/keys to mimic the original in this room. (all of) 36 -- I forgot.. item/object/key moved one left 37 -- Iron ...changed conveyor direction The others caverns/rooms are left alone---- ---------------- Item/Object/Keys where originally placed without the position data for the rooms. Conveyor data was not copied. so item/object/keys and conveyor direction are hit and miss. My primary concern was writing an editor - Which does allow 100% of the above to be corrected via the editor. But I suppose it is better to have a version that is playable, rather than have a version that needs editing before playing. The irony is that the editor does allow me to easily duplicate the data that was not copied from the original. Which might have been easier than editing the data that was present. v6c5 has been deleted v6c6 the final version is listed on the very first post

Very similar to the last download. (v6c3) I have moved the start platform right and Willies start position along with it. This has added the forced lap after collecting the last object. By making the jump from the start position onto the platform above impossible. But having the jump back onto the start platform now possible (from the tall right wall) - means the original route can also be changed. This version has been deleted - final version V6c6 is listed on the first post

Cavern 26 The Cloning Facility scope of editing. I am not changing the code, just the data. I am not aware of any memory available to edit the code. This means that an action caused by Eugene or Kong/Switch has to mimic/duplicate the action of the original code, and not have their actions/scope extended. Eugene just activates on last key/object collected - no deletes of wall etc Kong activates on switchs, which means the switch can be flipped at any time in any key/object collection order. This will erase a wall on switch activation. Whilst I allow the position of the wall to be specified. It will still modify a sprite. (To ignore the modification, I can place a blank sprite over the modified sprites slot.) Deleting the bush on the conveyor on switch activation (in the edits I did) changes the way it is played. So the easiest option is to move the offending key/object. Since I went through the code for the switch and how it activates, I did add the switch which does not change the collection order for all the other keys/objects--- Problem might be the time needed to collect all the keys/objects in the cavern. NOTE I HAVE NOT COMPLETED THIS CAVERN. (not attempted) Yet another version V6c3. --- (deleted only final version available) At a later date - the miner change versions prior to the final V6cX will be deleted Addendum :- if this needs to be more difficult and plenty of time left. Then I can/could place a nasty on the top platform to force another lap ---. (only the final version V6c6 is now available and is listed on the first post)

Which ever path you take grass hopper, the path behind will be closed. If version v6c2 is playable then the other versions will be removed.

Errors in data for Manic 40 Miner v6c Since this was the last version - I am not modifying code - but I will modify the data. Two versions - V6c1 and v6c2 - Take the path grass hopper. both versions add another platform above the portal. V6c1 removes the crumbling conveyor platform V6c2 Leaves the crumbling conveyors alone. The removal of crumbling conveyors was because I expected a graphic problem, Having jumped on a few in the room itself ( I added a few and tested what happened) I reverted back to the original crumbling conveyor platform. Files listed alongside the original V6c The path that is taken - will remove the path behind.

I have replaced the file V6c in the linked post above. Not aware of deleting . I did however edit the instructions page and remove all the blank lines and spaces. I will not edit this file for at least a year, probably never. What the file showed me was it would far simpler to write an editor in something like QBASIC64. I spent a couple of days doing a screen editor for manic panic in QBASIC64. It is a feasable thing to go further and write an editor for the whole game. With less effort I could write an editor for Manic 40 Miner. By doing it in qbasic64 I do not have any memory constraints. Whilst I looked at the question of writing an editor. I stopped myself from actually going further. The reason being the vast quantity of variables in Manic Panic that can be edited in one way or another. The prgram I wrote was just a few hundred lines of code. (actually 864 lines) Manic 40 Miner would be a lot easier, just not particularly interested in doing so.

Concerning Manic 40 miner. Response to the above questions about Manic 40 Miner 1) The version should be playable and finishable. I have/had no intention of creating a new version. The data started as an amalgamation of two sets of data (I think that is stated in the scrolling message). I then edited some of the screens and added a part editor..... The editor part, was what I was concentrating on, not the game part. Hence the statement it is a test routine. 2) No other versions are planned. It might actually be impossible to update. This year and last, I have suffered more crashed and corrupted hard drives and ssd's than in the previous 30+ years combined. Around four drives I think! (without specifically checking) 3) Ok ---- I have not seen the code for this version on any of my backup drives. It is possible that all the code is on a dead drive. Addendum - I have checked ... it appears I have the source code and the room source code/data. Last version I have assembled is version 6c. No immediate plans to update. I concluded that editing the game in z80 with the code as well is not the ideal way to do it.

The short notes that accompany jsw2+ was never really updated, for the subsequent updates. Those note are in essence mostly what the first and original version of JSW2+ did. In those notes it talks about a short maze. That maze is NOT seen in any of the updates writen after the test version. What the maze did was present the player with what appeared to be very similar rooms. Those rooms were interlinked in a complex cross cross logic and unfortunately the logic was complicated enough that the people testing the routine, could not work out how to escape the maze. I have played the maze and when told the sequence needed to escape from it. Using the specified logic, it was a simple enough thing to repeat and escape. However it was concluded that the logic, whilst it never changed - Was not in keeping with the simplicity the rest of the game exhibits when moving around. The Maze rooms were moved and placed in a linear fashion as Glitch in holodeck x. The complex room logic removed and since it was plugging the hole that escaped the NCC1501 (via a death contact). The multitude of objects were added to compensate for the loss of life. So the Maze does not exist in the final version. Addendum. The maze was originally between top landing and first landing.

A variant with 40 levels --- How about Manic 40 Miner... Designed as an editor . but still has 40 levels.

Follow on:- Available on E-bay for £14.95 + £3.00 P&P No idea of quality or any other aspect. https://www.ebay.co.uk/itm/194237192617?hash=item2d397059a9:g:a5AAAOSwwlVgNDbf

reference TobyLobster/jsw2021 from GitHub Quote:- Documenting the Remaining Minor Differences The jump parabola shape is very slightly different (while still being the same height and length overall) since the code seems to have problems with odd numbers of pixel height changes within the jump. This makes only a few minor changes overall: Nomen Luni: On the BBC you can jump from the top of the slope, under the Moon enemy to land on the platform under the ledge. On the Spectrum you have to jump to the lower platform first. The Bow: to jump up from the platform next to the wheel item needs two platform tiles instead of just one. Top Landing: Jumping into the Chapel area lands on the top level of flooring not the tiles below as on the Spectrum. The Forgotten Abbey: The platform under the item should be a wall, but changing this means the player can't fall down past it, trapping them at the top of the room. All the differences above match what is seen in the Spectrum's JSW II, so I imagine the jump parabola there matches the BBC version. A correction to the above statement- highlighted in red. JSW II uses the correct parabolic data. The reason -The Bow-, has two blocks instead of one in JSW II is the consequence of JSW checking the wrong blocks. This also causes the bug of passing into floors when jumping in -the First landing- going towards -the Chapel-. The code in JSW does not handle the double crossing of block edges, when entering a new block diagonally. That is when it moves both vertically and horizontally across a block boundary. This also is the reason why JSW II can clear the wall in the Garden and the same move is impossible with the code of JSW.

Spider wrote I kept thinking about the Eugune 'removal or harmless' cheats I wrote but they sort of spoil it a bit. What I could do with is something to either: > Slow his descent down to about half its current rate or > If he is moving upwards when the last object is collected, do not make him move down until he's reached the top. This has both advantages and disadvantages. I'm thinking more along the lines of the first option, if there's no sane space a quick JR out into a bit of dead area would do just fine. My response follows with two pieces of code:- First of the two posts was half speed Eugene on object collection. e.g. Eugene moves up and down as normal Until last object is collected then moves only downward. Eugene's speed is slowed to half its normal speed and Eugene finally stops when over the portal The second was ignore direction change for Eugene - E.g. Eugene moves up and down as normal until the last object is collected. From then onwards Eugene will continue moving as normal but will stop when over the portal. (this removes the forced direction change to only downward on all objects being collected)

; eugene keep movement - lock on portal org #8df8 move_eugene ld hl,#80dc ; Y POS LD DE,#80DB ; DIRECTION ld a,(de) ; the direction or a jr z,descend ;else going up - ignore possible collection of all objects ld a,(hl) ; y position dec a ; move eugene up jr z,change_dir dec (hl) jr draw_eugene descend ld a,(hl) cp #58 ; PORTAL POSITION jr z,change_dir_maybe inc (hl) jr draw_eugene nop ; pad out nop nop nop nop nop nop nop nop nop nop change_dir_maybe ld a,(#8074) ; last item attribute or a jr z,draw_eugene change_dir ld A,(DE) XOR 1 LD (DE),A draw_eugene ld a,(hl) ; from here #8e27 the same as the old code ; FROM HERE ---- THE OLD CODE and #7f ; as old code end move_eugene

Half speed.... ;eugene slow org #8df8 move_eugene ld hl,#80dc ; Y POS LD DE,#80DB ; DIRECTION ld a,(#8074) ; last item attribute or a jr z,descend_slow ld a,(DE) ; the direction or a jr z,descend ld a,(hl) dec a ; move eugene up jr z,change_dir dec (hl) jr draw_eugene nop ; my code is smaller - so pad out nop nop nop descend_slow ld a,(#80bd) ; game clock - steps in 4 bit 2,a jr z,draw_eugene ; slow to half speed descend ld a,(hl) cp #58 ; PORTAL POSITION jr z,change_dir inc (hl) jr draw_eugene change_dir ld A,(DE) XOR 1 LD (DE),A draw_eugene ld a,(hl) ; from here #8e27 the same as the old code ; FROM HERE ---- THE OLD CODE and #7f ; as old code end move_eugene

Cunning - I assume that the revised routines are passive. The original added blocks to an exposed face, actively over writing the screen with the new block I assume the revised routine adds blocks to the hidden faces - passively adding blocks with no overwrite of existing blocks. I will come back to this when I have the time to do so.

When the routine Block.tap was listed. (written in basic) I wondered if the same type of routine could be used to generate the familiar JSW title logo. So I wrote something that emulated the visuals of the basic. Whilst that code took an hour to write, I could not generate the JSW logo using the routine I wrote. It can draw what looks like the LOGO with a flicker. The Flicker is the result of not being able to stop the drawing at any point, with the graphics needed. It has to keep on updating the screen to form a flickering image. So a failure and not what I wanted. This is the Block Tap equivalent in Assembler. Hold "A" to slow down to the speed of drawing the basic blocks. Hold "D" to freeze LOGO_G.tap

Best viewed from the moon. e.g. not close pulsing Psychedelic This uses two separate routines to move colours - the colours are then merged. PULSE.tap as usual - I looked at the code - it was not quite what I wanted . Pulsar is more symmetrical in code and output. This separates the bright ink and paper - so this uses 3 routines and then merges them pulsar.tap