Spider

I remember it being 'scrolly' rather than 'room to room' :) I think another version is like that too, possibly the Archimedes one :unsure: I do have it somewhere so I may have to try it again to refresh my memory on this. I seem to recall it was not "quite right" with regards to the jump movement but I could be completely wrong here and thinking of a different version...

I've seen the collection photo just now. :) *adds friend request on FB*

Yes, Spectrum version at least. See here > http://maps.speccy.cz/map.php?id=JetSetWilly2 Come to think of it I think in JSW1 in some versions (BBC and possibly MSX, I'd have to check) all their screens are black.

I'd agree with that. :)

He is a member here so he may see this and reply. :) Room numbers, well with 8 bits you can have 256 (0 to 255) 'numbers' as such'

In a nutshell, your last main sentence was correct, it would need rewriting to do this. :) The compression I use simply compresses it as much as possible. To do what you're asking you'd need the decompressor present all the time (not a problem) then 'uncompress' bits of code into say a designated area of memory. When a 'new' bit was required you'd simply decompress some other part into this 'designated area' :)

:) Thank you.

I wanted to expand (no pun intended!) on this for you once I had a bit of time to do 'something' ;) With a new turboloader and compression, I've achieved the following using the standard Software Projects release of Manic Miner. Some quick specs: Standard MM: Total Loading Time: 3 min 9 seconds Tape length: 3 min 35 sec Compressed + Turboload MM: Total Loading Time: 0 min 56 sec Tape Length: 0 min 58 sec Yes, under a minute all in. :D It can go higher but this (4500 baud) is about the top limit for a 'real' tape and you'd need a decent one to do this I think. Manic Miner Compressed Fast Load.tzx Basic Loader: 10,20,30,40 : Just some basic (no pun intended) details 50 : Black screen and set Ramtop (CLEAR) 60 : Load the 'pic and loader' code in at 65102 and its 435 bytes in total. Call it (651E2 = 65100) 70,80,90 : Put your pokes if required here 100 : Tiny pause then start the game Here is the actual 'pic data' , as you can see its about the minimal number of blocks I could save to get it to work. Note its not animated in this so the starting and ending of the letters is the start/end: Tape structure: Details of the 'combi' screen and loader: 65102 starts here: LD HL, 65122 ; Setup to move 219 bytes from 65122 to 22818 LD DE, 22818 ; 22818 is most of the middle screen attributes LD BC, 219 ; to 'draw' the loading graphic blocks LDIR ; Move them! NOP ; Do nothing CALL 65343 ; Call the loader RET ; Drop back out to Basic ** The 'code' between these two is not really 'code' as such it is actually just data: The 'graphic blocks' to move ** 65343 (almost as there's a half a dozen bytes before this but they are not relevant to this) LD IX, 32768 ; Tell the turboloader that we are loading at 32768 LD DE, 16296 ; and its an expected length of 16296 bytes long CALL 65359 ; Call the turboloader now, when its finished it returns here (CALL = GOSUB) JP 32768 ; Call the uncompressor ** The 'code' following this is the turbo loader itself ** No point posting that. Without calling the uncompressor, we'd return to Basic with the 'compressed' code still (32768,16296) which would not be too helpful to use, so it makes sense to 'uncompress' it before returning. We could go a stage further and change the RET at 65117 to JP 33792 to 'call' the game code which would mean there was never a return to Basic but the idea of this is not to attempt any form of protection it is merely a fast load of a compressed block. Doing this though there is a little risk of the code being 'uncompressed' over itself (when it was looking for the next instruction after calling the decompressor code) which could result in a crash. There are easy ways around this should it be needded though. The quick and easy way is to simply stick those few 'call the decompressor' bytes into the screen out of the way and run it from there.

I think its the way the entities in the URL are that's doing that. Might be browser specific too. UTF8 vs ISO etc

http://www.the-tipshop.co.uk/cgi-bin/info.pl?name=Jet%20Set%20Willy%20-%20The%20Nightmare%20Edition

To expand on this a bit, this is 'compressed' Manic Miner (Software Projects version simply as I had that to hand) no cheats or anything else applied: Tape Structure: Basic: Notes: 10 Setup colours etc 20 Load the pic code. This is not a direct attribute load its a code file that will LDIR (move) the blocks into the correct place. Its a bit smaller that fully screen (768) or the middle (256) bytes. This also means it instantly appears rather than being 'drawn' 30 Call that 'code' to display the loading pic 40 Load the compressed game code 50 Call the game code at a certain place to uncompress (expand) it to where it should be and its proper size 60 Obvious :) 70 Call the game I thought about a high baud rate to reduce it a lot (say 3500 compared to 1500) but that would be a step too far maybe. Anyway the game code is now 15KB in size instead of 32KB , a substantial loading time saving.

Its fine. I did consider just PM'ing you the information but as its been out a few months anyway and The Tipshop has the 'immunity' cheat anyway there was nothing to hide really. :)

It would be in theory quite easy to "turn it back on" although in TNE bear in mind some of the code has been moved to make space. This does work but the effects are highly unpredictable. If you wanted to try this, apply the following in an emulator: 59900,69 59901,213 The second one is not completely necessary I think but that will switch it 'on' if the arrow descriptor is in the correct place. Next, lets start him in The Attic so he's got less travelling to do to get there: 34795,41 Some immunity is really going to be needed to help here too: Lastly, stay still in the Attic until you hear both arrows fire. You'll only see one though. Now its time to explore. Best plan: Head left (you can walk through fire cells now!) and down. Aim for Back Stairway > Cold Store > Kitchen > Then expect chaos. Given this destroys the game, I've not assembled a tape file for it. Erm, enjoy ? :D

I have heard of it, the same as the Amiga and Archimedes versions too as in I've heard of them. I'm not sure if they were 'official' or not though :unsure: It is likely (hopefully!) the 'unfinished' one is floating about somewhere.

I do like that idea. I seem to remember that given the way (on a PC at least, a Mac might be a bit different) it can be difficult to get all the codes into the keyboard as the way the PC reads multiple keys being depressed is a bit different. I could be wrong... :unsure:

This is JSW1. It does work. But you have to uncompress it before running the code. The compression in this case is just to reduce the 'saved' file size down. :)

Well I guess that's true. But you'd need some kind of 'on the fly' decompression to 'test' it as you'd not really be able to reliably edit a compressed file. Think of this as trying to edit say a .zip file "directly" with a hex editor. At least that's how I see it, I could be completely wrong. :) This saves quite a bit of loading time on a 'real' machine or emulated for 'tape emulation freaks' (such as me!) From various bits of research ( ! ) they were going to be part of the MegaTree. There was something he said once (well, so I read) along the lines of the fact the tree was meant to be a lot bigger, so I'd assume that is where at least two if not more of them would of been.

Oh in the path of the rope ? :o :) Would that not cause an IDS ? :unsure:

The only use of this I can think would be where you need to climb up a rope to avoid say a row of floor nasties then climb down and exit the rope to run across some crumblies. The rope would have to be not central in most cases, say starting at 4 to 8 blocks in from the left. :unsure: Its an interesting thought though, but I would think once he'd landed on the crumbly, the 'reduce the floor!' part would start it may just take another game tick or two before the main loop 'saw' where he was standing and started this.

The issue with compression is when its unpacked it takes the same size as the original did, unless I'm missing something ? :) I can compress JSW down to about 18K in some cases ( ! ) but it won't run in that state. :D

Slightly off topic but I like the ROM Disassembly. :) Having read the book about it, the info you've provided (from what bits I've looked at so far) are very helpful.

To clarify this a bit: Sinclair Joystick on Interface2 (left socket) 1=left 2=right 3=down 4=up 5=fire Sinclair Joystick on Interface2 (right socket) this is the one most used: 6=left 7=right 8=down 9=up 0=fire 'Cursor' interface Joystick: I don't think these were too common 5=left 6=down 7=up 8=right 0=fire Kempston: Not 'directly' mapped to any keys so its popular. Can be read from Basic too with IN 31 such as: 10 PRINT AT 0,0;" " 20 PRINT AT 0,0;IN 31 30 GOTO 10

I do not use them either. Bear in mind part of the reason for those keys to control him was for the Sinclair joystick option (which used 67890 or 12345) but that's not of much practical value these days, emulation tends to use Kempston anyway The only caveat would be someone on a real machine (a +2 / +2A / +3) using the built in joystick ports as these *are* those key combinations. :)

:lol: well that's true. Oh I see sorry. :) , I thought it was in a PM for some reason.

POKE 35681,255 / #8B61,#FF POKE 35682,255 / #8B62,#FF POKE 35683,0 / #8B63,#00 POKE 35684,0 / #8B64,#00 Tested. That is very slow :) Its about a frame a second. I was not sure why you were bumping the topic. :) Hence the post above this one with a 'retest' of the values, all four.