Nemesis - The Wizardry Adventure (1996)

[Python-Exoproject]

Suffers from mouse acceleration bug.

Tested Dosbox-Staging and it fixes the bug but is currently missing other needed features. Test again with future releases.

[Burrito78]

Staging now has feature parity with ECE. Are other features needed? Can you switch now?

[Python-Exoproject]

Cant remember why this might have been closed as its still on ECE and the mouse acceleration issue is still present. As Buritto noted Staging has come along way since the initial post and is now fully capable of handling the game. Please find a conf for Staging here: dosbox.zip

[exoscoriae]

interesting. fixed.

[parricc]

The game crashes when you exit the initiation chamber (the starting room), go two steps forward, and try entering the building on your right.

[interloper98]

My guess is @Python-Exoproject and @exoscoriae will hit this same problem on Windows.

There's something strange going on with the CDROM images.

The game's trying to open D:\FLICS\SEGU\ENTRANC!.SMK (shown in the error message from @parricc), however if you mount the BIN/CUE, that exclamation becomes an underscore D:\FLICS\SEGU\ENTRANC_.SMK:

I tried other DOSBoxes (74, SVN, and X), however they all behave the same.

I thought, maybe DOSBox just isn't handling this disc image correctly, so I used Linux tools to convert the BIN/CUE to an ISO and then list the files, totally separate from DOSBox:

isoinfo -l -i cdrom1.iso

Directory listing of /FLICS/SEGU/
d---------   0    0    0            4096 Oct  6 1996 [     31 02]  . 
d---------   0    0    0            6144 Oct  6 1996 [     21 02]  .. 
----------   0    0    0          327337 Apr 11 1996 [ 255671 00]  1_.SMK;1 
----------   0    0    0          487188 Apr  1 1996 [ 255433 00]  2_.SMK;1 
----------   0    0    0          623644 Apr  1 1996 [ 255128 00]  3_.SMK;1 
----------   0    0    0          417304 Apr  2 1996 [ 254924 00]  4A_.SMK;1 
----------   0    0    0          578716 Apr  2 1996 [ 254641 00]  4B_.SMK;1 
----------   0    0    0          362584 Apr  2 1996 [ 254463 00]  4C_.SMK;1 
----------   0    0    0          963957 Apr 10 1996 [ 253992 00]  BENIN_.SMK;1 
----------   0    0    0          743688 Apr 10 1996 [ 253628 00]  BENOUT.SMK;1 
----------   0    0    0            7352 Apr  2 1996 [ 253624 00]  BEN_1.SMK;1 
----------   0    0    0          411404 Apr 11 1996 [ 253423 00]  BEN_10.SMK;1 
----------   0    0    0           12612 Apr  4 1996 [ 253416 00]  BEN_11.SMK;1 
----------   0    0    0           25168 Apr  4 1996 [ 253403 00]  BEN_2.SMK;1 
----------   0    0    0           16348 Apr  4 1996 [ 253395 00]  BEN_3.SMK;1 
----------   0    0    0            5924 Apr  4 1996 [ 253392 00]  BEN_4.SMK;1 
----------   0    0    0          419312 Apr  4 1996 [ 253187 00]  BEN_5.SMK;1 
----------   0    0    0           12548 Apr  4 1996 [ 253180 00]  BEN_6.SMK;1 
----------   0    0    0           11252 Apr  4 1996 [ 253174 00]  BEN_7.SMK;1 
----------   0    0    0          397608 Apr  4 1996 [ 252979 00]  BEN_8.SMK;1 
----------   0    0    0           53688 Apr  4 1996 [ 252952 00]  BEN_9.SMK;1 
----------   0    0    0           96976 Aug  6 1996 [ 252904 00]  BOOK1.SMK;1 
----------   0    0    0          127576 Aug  6 1996 [ 252841 00]  BOOK2.SMK;1 
----------   0    0    0         1200388 Jul 24 1996 [ 252254 00]  CHRCHOUT.SMK;1 
----------   0    0    0         1167664 Jul 24 1996 [ 251683 00]  CHURCHIN.SMK;1 
----------   0    0    0          695540 Sep 19 1996 [ 251343 00]  CRYPTLV2.SMK;1 
----------   0    0    0          569052 Jul 11 1996 [ 251065 00]  ENTER_E.SMK;1 
----------   0    0    0          366136 Jul 11 1996 [ 250886 00]  ENTER_N.SMK;1 
----------   0    0    0          970436 Jul 11 1996 [ 250412 00]  ENTER_W.SMK;1 
----------   0    0    0         1999035 Jun 17 1996 [ 249435 00]  ENTRANC_.SMK;1 
----------   0    0    0         1220543 Apr 10 1996 [ 248839 00]  EXIT_.SMK;1 
----------   0    0    0         1027296 Sep 19 1996 [ 248337 00]  FORSTLV2.SMK;1 
----------   0    0    0         1126849 Aug 30 1996 [ 247786 00]  GUILDIN.SMK;1 

Hmm.. we see the same underscores here too.

Dumping more info about the header:

isoinfo -d -i cdrom1.iso

CD-ROM is in ISO 9660 format
Volume id: NEM_CD1
Application id: NERO BURNING ROM
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 316443
Joliet with UCS level 3 found
NO Rock Ridge present

What's interesting here is that the disc has Joliet data (a Windows 95+ format), and it was also burned (or perhaps dumped) using NERO BURNING ROM.

So it doesn't seem like a strict "DOS" ISO 9660-only CDROM.

I don't know if this was caused by the person dumping or ripping the disks or if that's how the game company intended it (and maybe were using some latest-gen MSCDEX or even running DOS from within a Windows 95 environment where perhaps those Joliet records could be used).

The disks have no CD audio tracks, so I suspect we can dump the Joilet records and make compliant 9660-only ISOs (and keep them along side any archival BIN/CUEs).

Will poke around a bit more.

[interloper98]

@parricc , here are step-by-step notes on how to generate correct ISOs from the incorrectly ripped BIN/CUEs:

1. Confirm you have bchunk, genisoimage, and bsdtar:

   which bchunk
   which genisoimage
   which bsdtar

   Find and install packages for them if needed.

2. Enter your eXoDOS Nemesis CDROM directory:

   cd eXoDOS/nemesisw/cd

3. ls -1, confirm you have the five BIN/CUEs in your current dir:

   'Nemesis CD1.bin'
   'Nemesis CD1.cue'
   'Nemesis CD2.bin'
   'Nemesis CD2.cue'
   'Nemesis CD3.bin'
   'Nemesis CD3.cue'
   'Nemesis CD4.bin'
   'Nemesis CD4.cue'
   'Nemesis CD5.bin'
   'Nemesis CD5.cue'

4. Paste the following block of shell commands into your Bash shell to generate five working ISO 9660s from the five broken BIN/CUEs.

   for i in $(seq 5); do \
     bchunk Nemesis\ CD$i.bin Nemesis\ CD$i.cue track \
     && mkdir content$$ \
     && bsdtar xfp track01.iso -C content$$ \
     && rm -f track01.iso \
     && genisoimage \
       -o cdrom$i.iso \
       -appid "" \
       -P "Virgin INTERACTIVE entertainment" \
       -sysid "" \
       -iso-level 1 \
       -untranslated-filenames \
       -V NEM_CD$i \
       content$$ \
     && rm -rf content$$
   done

5. Confirm you now have 5 ISOs inside the cd/ directory alone side the BIN/CUEs. ls -1 *.iso:

   cdrom1.iso
   cdrom2.iso
   cdrom3.iso
   cdrom4.iso
   cdrom5.iso

6. Note these are proper ISO 9660s without any Windows (Joliet) or macOS (Rock Ridge) structures isoinfo -d -i cdrom1.iso:

   CD-ROM is in ISO 9660 format
   System id: 
   Volume id: NEM_CD1
   Volume set id: 
   Publisher id: Virgin INTERACTIVE entertainment
   Data preparer id: 
   Application id: 
   Copyright File id: 
   Abstract File id: 
   Bibliographic File id: 
   Volume set size is: 1
   Volume set sequence number is: 1
   Logical block size is: 2048
   Volume size is: 316396
   NO Joliet present
   NO Rock Ridge present

7. Test the new ISOs in DOSBox Staging (here's the adjusted eXoDOS dosbox.conf autoexec snippet with pause to inspect the active mounts):

   [autoexec]
   mount c eXoDOS 
   imgmount d eXoDOS/nemesisw/cd/cdrom*.iso -t cdrom
   mount
   pause
   @c:
   @echo off
   cls
   echo.
   echo This game is composed of 5 cd's.
   echo.
   echo To switch cd's press Ctrl+F4.
   echo.
   pause
   cls
   cd nemesisw
   @call run
   exit

   (Tip: you can use wildcards in Staging's imgmount line and the forward slash paths are compatible across Windows, macOS, and Linux.. so the above should work on all systems)

8. Launch.. hopefully it works!

[interloper98]

md5sums:

9c141522b57084d7ea8cc0e0ef7ec729  cdrom1.iso
996412e6c5e63a581a450f355e011e7c  cdrom2.iso
e17495e46d4fbf9f11d7577bfb4d1dc2  cdrom3.iso
3436b78df2cfc141863ab721510573ae  cdrom4.iso
af6fe5289f8a38a80764ec17cd503286  cdrom5.iso

I've uploaded them here if anyone else wants to try: https://file.io/Jd3VTzhgCrmQ

[parricc]

The iso files worked with what I tested.

[interloper98]

Thanks for testing them, @parricc.

The TLDR of the problem is that the rip of these BIN/CUEs is bad.

Whoever did it forgot to allow the relaxed character set for the ISO 9660 filesystem, which damaged the original filenames (Filenames containing the ! character were squashed to underscores _). This isn't only a problem for DOSBox; real MS-DOS PCs won't be able to use the BIN/CUEs, either.

Fortunately the Windows Joliet filesystem in the images do contain the original filenames (because Joliet is more advanced and allows more characters). The fixed ISOs takes the correct Joliet filenames and puts them back into the ISO 9660 filesystem so DOS and MSCDEX can read them.

[exoscoriae]

the problem is we are degrading these to ISOs

[exoscoriae]

and the files posted above are now long gone.

[interloper98]

the problem is we are degrading these to ISOs

np; I'll regenerate them as a bin/cue.

and the files posted above are now long gone.

I saw people talking about "uploading to github" on Discord; but as far as I can tell GitHub doesn't allow massive attachments; I'll re-upload to file.io and let you know when they're ready. I think file.io has a 2 week expiration period.

[SmilingSpectre]

@interloper98 "Github" in this context usually means "Github folder of Synology server of the project", not the Github site.

[interloper98]

@interloper98 "Github" in this context usually means "Github folder of Synology server of the project", not the Github site.

Thanks @SmilingSpectre .. here I thought you guys had VIP level access! :tophat:

Repack is almost ready ...

1 folder, 10 files, 3525963553 bytes (3363 MiB)

Creating archive: nemesisw-fixed-bins.7z

Add new data to archive: 1 folder, 10 files, 3525963553 bytes (3363 MiB)

 68% 6 + nemesisw-fixed-bins/Nemesis CD4.bin

[interloper98]

Reposted them as bin/cue. I had to split the 7zip archive into two parts. Here are the download links. Grab 'em before Oct 10th (if not, I can repost them).

• nemesisw-fixed-bins.7z.001
• nemesisw-fixed-bins.7z.002

After extraction, you can use 7zip's checksum feature to verify the files, here are the md5sums:

acb27554c42919f39f321929395e3888  Nemesis CD1.cue
ff6a0a8ddaf4b27d3dcbe67b02762b24  Nemesis CD2.bin
16987181ae2b216e9296b336d9c3b223  Nemesis CD2.cue
ceb3d62c87c7acd446f0c978b7694b2c  Nemesis CD3.bin
6bcab46344d2d87343e7b4ba7b505528  Nemesis CD3.cue
b6cacbbcb985fcbc908e4507f8f85878  Nemesis CD4.bin
d2c09265ef9d074a691a33d93f223202  Nemesis CD4.cue
d7298aacb7c5bdc786e4a5dab15f4b8a  Nemesis CD5.bin
74cfa1c8acdeefe3d9644e3f0be5a8a1  Nemesis CD5.cue

[SmilingSpectre]

What exactly did you do with these transformations above?

[interloper98]

What exactly did you do with these transformations above?

It's explained more in my prior comments, and the Linux tools and commands are all provided.

The fixed filenames are taken from the non-DOS Joliet filesystem that was fortunately still in the incorrectly ripped bin cues, and the filenames placed into the iso9660 filesystem. I then repacked those back into bin cue.

[SmilingSpectre]

Mhm. Thank you.