I beg to differ.
My research shows that the demon doesn't appear in episode 1 at all.

The first time it appears is in E2L9 ("Heck") and that level has a whopping 16 demons. Even though the game gives you three spinblade weapons right at the beginning of the level, I think it's impossible to beat that level in the later versions without dying at least once. There are 13 demons you need to get past before you get to the first apple and you don't have nearly enough health to just run past the demons. There is only one other level in episode 2 that has a demon and that's level 13 where you only have the knife and need to get a key from the "demon's hideout". I'm not sure if you're supposed to be able to kill that demon with 6 hits or just avoid it, grab the key and get out of the area.

Episode 3 has one demon in level 2 and you get three knives right at the start of that level. Again, I'm not sure if you're supposed to be able to kill the demon or not (knives can hurt the demon in v1.0), but you can just avoid it. Level 11 has 5 demons in it and starts you off with three knives, but you get one spinblade weapon before you meet the first group of four(!) demons. Again, I think it's very difficult to kill all four in the later versions without dying at least once, but you might be able to just run past them and survive. The fifth demon guards the key to the exit, so you can probably kill him or just walk past him. There are also a couple of apples near that demon.

There's probably no definitive answer here. If you ask me, there has to be a reason why the GOG release only has the early/easy version of episode 2, but the later/harder version of episode 3 (I haven't seen the executable of JILL3 v1.0 so I don't know for sure if its the code would be any different from v1.0 of episode 1 & 2). Don't get me wrong, this doesn't make the game unwinnable since you just respawn after death and the level doesn't reset. I simply feel that having to rely on respawning to make any kind of progress is terrible game design.

Or maybe I'm just misinterpreting here. The level is basically "Hell". Can you actually die in hell? When you die in hell, do you go to hell - which means back to the level entrance? Was having to die over and over and over how you were supposed to play that level? I don't know...

Update: I had the opportunity to look at v1.0 of JILL3.EXE and now I can confirm that the code for the demon and the spinblade weapon is the same as in v1.0 of Jill 1 and Jill 2 (the machine code is not 100% identical due to different compiler optimization settings, but the original C code would have been the same). Jill3 v1.0 also has the 0x400 bit set, so the spinblade weapon kills the demon in one hit while any other weapon kills it in 6 hits.

Slightly off-topic rant:
One big difference I noticed when comparing the first release of Jill 3 to Jill 1 and 2 is that Jill3.exe is the first release that contains code that checks if the name of the shape file (hard-coded as "jill3.sha" in the executable) begins with an 'o'. In case you didn't know, Tim Sweeny created a christian-themed game called Onesimus - A Quest for Freedom for Ark Multimedia Publishing based on the same code as Jill and sharing a lot assets (maps, sounds, graphics) with the Jill games. This proves that at least some code specific to Onesimus was added to the shared codebase before Jill 3 was released.

To be fair, the creator of the video I linked to above mentions that Onesimus was created alongside Jill 3, but he also claims that Onesimus was a rehash of existing Jill levels. That's not entirely true, at least not for Jill 3. If you open the file "2.JN3" in Jill's built-in level editor and scroll to the top of the level, you will find the complete ending sequence of Onesimus in that level. So at least in this case Jill re-uses a level made for Onesimus and not the other way around. Other levels like "Aqueduct" (6.JN3) also seem to be examples of Jill 3 re-using levels created for Onesimus, at least if you know what an aqueduct is.

To use the built-in level editor, press CTRL+E at the main menu. In the editor, hit L to load a level (enter the file name and hit ENTER to confirm). Use the arrow keys to scroll.

By the way, the Jill source code appears to be designed from the ground up to make it easy to replace any Jill references, which is what Onesimus does. On top of that, even v1.0 of Jill 1 and 2 contain code for objects named "PAUL" and "ROMAN", so the intention of creating Onesimus must have existed before v1.0 of Jill 1 (or what is assumed to be v1.0 anyway) was ever released.

so the intention of creating Onesimus must have existed before v1.0 of Jill 1

Tim: "We're coding a wholesome game for Christians."

Sales manager: "I'm worried about... limitting our demographic; can you make the engine flexible?"

milliseconds pass ....

Sales manager: "Got it! Scantily clad, kick-ass amazon jungle babe. Demographics covered."

So, shall I update my patch to use v1.0 spinblade behavior in all three episodes? And if so, where are the relevant bitmasks in the current "final" (post-patch) .EXE files of Episodes 1-3?

I don't have your patch installed at the moment, so I can only give you some info for the unpatched JILL1 v1.2d:

The flags for the demon objects are initialized at seg015:0198, so changing the bytes at offset 81BC (from the beginning of the .EXE file) from 00 00 to 80 04 (all hex) should do the trick. Of course this is pointless since the demon doesn't appear in episode 1, but I hope this helps you figure out how to find the offsets for 2 & 3. The instruction directy before the one that sets the flag is the one that assigns the offset of the string "DEMON" to a variable, use that to find the correct bytes to patch. The offset of the demon code is set before the name is assigned, which should help you compare the v1.0 demon code to the later demon code (if you want to make weapons other than the spinblade hurt the demon).

I guess the best idea would be to make this part of your patch optional, so that anybody who actually wants to play the games on hard mode can do so.

I certainly will not create à-la-carte patches. If it cannot be figured out which alternative is correct, I will not patch it. So nevermind.

Well, I finally had the time to look at the executables after NewRisingSun's patches are applied. They differ a lot more from the regular 1.2d than I thought, so the offsets I mentioned earlier won't work.

If anyone wants to mod the fully-patched executables to make the spinblade kill the demon enemies in one hit, you can use the following patch script along with this patching utility. Just copy the script into a blank text file, save it and let the patching utility open the text file.

1%exefile jjfile1.exe 195190
2%patch $650C $480w
3
4%exefile jjfile2.exe 194310
5%patch $650C $480w
6
7%exefile jjfile3.exe 194342
8%patch $650C $480w
9
10%end

If you can't run win32 programs (or you don't trust the patching utility), you can just use a hex editor and change the two 0 bytes at offset 0x830C to 0x80 0x04 (or change only the 0 at offset 0x830D to 0x04). The offset is the same for all three executables.

This information is based on the most recent version of the patch (posted 2017-05-21). Don't expect these to work on any earlier or later versions.

By the way, the current version of NewRisingSun's patch doesn't work on the GOG release because the JILL2.EXE in the GOG release is an "unknown" version of the file. And I also noticed that the scrolling is broken when playing the world map level of Jill 3 in CGA mode. That's because the CGA scrolling code is optimized for scrolling in multiples of 8 pixels, but the world map level tries to scroll in multiples of 4 pixels in VGA and CGA mode. I'm not sure if you would want to fix that, but I thought I should at least mention it.

K1n9_Duk3 wrote:

And I also noticed that the scrolling is broken when playing the world map level of Jill 3 in CGA mode.

That problem was not introduced by my patch, but is an original game bug, in all game versions. I noticed that the EGA version always snaps to eight pixel-scrolling, so if I am lucky, correcting this is just a matter of adding another value to a query of a video mode variable.

K1n9_Duk3 wrote:

there has to be a reason why the GOG release only has the early/easy version of episode 2, but the later/harder version of episode 3

I think they just cobbled together whatever version they could find. Given that the author of the game does not seem to be much of a help, based on that twitter comment, I don't think the version choice was a conscious decision based on the author's input.

NewRisingSun wrote:

K1n9_Duk3 wrote:

And I also noticed that the scrolling is broken when playing the world map level of Jill 3 in CGA mode.

That problem was not introduced by my patch, but is an original game bug, in all game versions. I noticed that the EGA version always snaps to eight pixel-scrolling, so if I am lucky, correcting this is just a matter of adding another value to a query of a video mode variable.

I didn't mean to say it was your patch that broke the scrolling, but I apologize if I made it sound like that. I was well aware that this bug is present in all original versions of Jill (and Onesimus).

SaxxonPike wrote:

For those of you who have waited for a legal online distributed version of this game, it looks like GOG has just released the whole trilogy for free today

Bit late to the party but this is really interesting! It's a shame they didn't include the episode selection screen that came with some versions, but I'm glad to see they didn't remove the Ctrl+E level editor!

Malvineous wrote:

It's a shame they didn't include the episode selection screen that came with some versions

I agree, but I also know that the menu program has some issues that would prevent it from working correctly with the executables from the GOG release. The menu basically expects to be started with a blank screen (more specifically, it expects to find the cursor at line 0 or line 1), otherwise the menu program will immediately quit to DOS. This also means that the menu expects the games to quit with a blank screen, which isn't the case in version 1.0 of the games. In the GOG release, this means you would be able to select each episode from the menu, but quitting episodes 1 and 2 would quit to DOS while quitting episode 3 would quit to the menu. This check was probably added to make sure that you actually get to see the error message when the game crashes, instead of having the menu pop up.

If anybody wants to add the menu program to the GOG release, you can either apply NewRisingSun's patch (once support for the GOG release is added to it) or copy the menu files from a shareware release of Jill (v1.1 from here has the files). The files you need are JJFILE0.EXE, JILL.BAT, JJFILEA.BAT and JJFILEB.BAT and you also need to rename the game's executables to JJFILE1.EXE, JJFILE2.EXE and JJFILE3.EXE. Run JILL.BAT to play the game(s).

Very interesting, I didn't know about those limitations! Makes sense though to avoid losing any error messages, although of course checking the exit code of the executable (the ERRORLEVEL) would've made things more reliable!

I have updated JILLUPD again. What is new:

• Now also supports the version from GOG.com
• Corrected PC speaker sound effects that were broken in the original v1.2d, and that failed to work at all when updating from previous versions
• Corrected occasional PC speaker sound effect dropouts caused by a timer interrupt occurring while the sound effect buffer is still being set up
• Corrected world map scrolling in Episode 3 when using CGA graphics
• Corrected v1.2b's menu displaying Kiloblaster game/episode titles in EGA/CGA mode
• HUD level number is now immediately updated when touching a mid-level checkpoint
• Always redraw tiles when elevators move
• Torches no longer cause damage when the fire is no longer visible
• Game no longer occasionally adds multiple knives to the inventory when touching a knife object
• The 8253/8254 Programmable Interval Timer is now reset when starting JJFILEx.EXE, so that hardware detection does not freeze when a previous program failed to properly uninitialize the timer

All this in addition to the issues that previous versions of the patch corrected:

• Restore map level jokes about Epic Megagames crushing the competition that were removed after v1.0 of the game
• Clear the high score table. Note that this also deletes any references to saved games, so if you want to keep them, refuse to overwrite JILL1.CFG/JILL2.CFG/JILL3.CFG when asked during extraction of the JILLUPD.ZIP file
• Wait 50 ms for an interrupt during IRQ detection (independently of CPU speed)
• Always set the DMA controller to auto-init mode, even as the SB DSP is programmed for single-cycle playback (workaround against SB16 DSP hardware bug)
• Send End-of-Interrupt signal to Interrupt Controller before IRQ detection (needed under Windows 98)
• Change sample cache slot memory buffer size from 6,144 to 12,228 bytes (prevents memory corruption manifesting itself in sound effect dropouts)
• Correct block size in auto-generated VOC header, add block type 0 at end (prevents possible freeze)
• Disable mixer writes (leave my mixer settings alone!)
• Use the BLASTER= environment variable for Sound Blaster settings
• Remove garbage write to I/O address 00h in graphics code, which prevented DMA channel 0 from working. Note that DMA channel 0 will not work in vanilla DOSBox, a limitation of the emulator, not of the Sound Blaster code/patch.
• Correct missing lava and water animation
• Update the screen when a switch is flipped
• Remove unnecessary symbolic information from executable files
• JILLFM/EPICFM: Play music through SBFMDRV.COM of the user's choice (supplied: v1.22, as in original release of the game)
• JILLFM/EPICFM: Exit with an error message if a memory-resident program (such as SBPVOL) that interferes with EPICFM.EXE is active
• JILLFM/EPICFM: Use the BLASTER= environment variable for Sound Blaster settings

Issues that have been presented which I have decided not to patch, because the intended behavior is not known:

• Demons could be killed in one hit using the spinblade in v1.0 of all three episodes, but not in later versions
• Phoenix in Episode 3 Level 3 hovers in mid-air without moving; the game data wants them to fly vertically, which the game engine does not support at all

Background and instructions for applying the patch. Only apply it to an unpatched game. Many thanks to K1n9_Duk3 for bringing various issues to my attention, suggesting possible ways of correcting them, and testing.

Another worthy game fixed to ULTIMATE status by NRS; thank you NewRisingSun and K1n9_Duk3!

I patched my GOG release and played all three with the improved FM music; huge difference across the board. I also especially like the game selection menu.

I must try these patches. It's been a while since I played Jill, but it might be fun to relive it with the improvements, and the kids would enjoy it. 😁

thanks NRS and K1n9_Duk3 !

That's very impressive. As a long time fan of the music, do you have any insight as to why the CMF player was changed? I didn't realise there was a version that *didn't* use the Worx toolkit, and also didn't realise there was a Creative SBFMDRV that supported stereo output. I wish there was somewhere where all this stuff was documented!

I assume they switched to using the Worx toolkit for its better PCM playback routine, and while they were at it, made use of Worx' .CMF playback routine. I wrote down my observations on CMF/SBFMDRV as background information included in the documentation of my CMF-to-VGM conversion utility. I would still like to obtain, and support, Dan Froelich's original .ROL-format files, because the conversion utility from .ROL to .CMF that Epic had to use introduces various errors.

By the way, the patch script and the offsets mentioned in this post are still valid after applying the current version of NewRisingSun's patches.

Very interesting! Nice collection of SBFMDRV versions too. I see from your notes that it is only a default kind of stereo support - I take it the driver doesn't respond to MIDI panning events?

Although I've written a few CMF players from scratch I haven't investigated SBFMDRV too closely other than trying to figure out how it handles a few edge cases, like percussive instruments that share an OPL channel being played at the same instant. When you say CMF files don't support volume changes to an already playing note, do you mean by this that the MIDI 'aftertouch' events are not supported? Although it's not very clearly described as such, this seems to be the way to handle volume changes on an already playing note with MIDI so it would be easy enough to include these events in a CMF file. I've never tested these events in a CMF though so not sure if they have any effect.

Also, I assume you're aware of this already, but Xargon's demo song (song_d.xr0) is also a great test case for whether note velocities are handled or not.

As another point of interest, ever since I had my first sound card many years ago, I always wondered why SBFMDRV changed the instruments when pausing and resuming a song. Sometimes it made the song sound quite good, and was a different way to listen to it. I don't suppose you've delved into the code enough to figure out why this happened? This was with the SB2.0 version, in case it is something they fixed with later versions. I have attached this version because it looks like it's different to those included in your CMF2VGM distribution. It says v1.34 (the SB16 one) but when you run it it only has support for SB1.5/2.0, so not entirely sure what that means (maybe OPL2 only?)