Realms of Darkness

[Hot Rod]

Hi,

Did Realms of Darkness ever get cracked? I see the images on Asimov are .nib, and I don't see it elsewhere.

I recall looking at this way back when, and had created a cracked first side (which I apparently no longer have, as it wasn't in my disk collection). Anyone ever see it?

I think I also wrote up a description of how to crack it - I might have that still.

]HR

[Antoine Vignau]

I think I have a cracked version. I'll check when I'm back from my business trip in two days,
Av

[Hot Rod]

Well, I'll reply to my own post. I did find the write up I had created for cracking Realms of Darkness. It apparently put me in a pretty crabby mood at the time, so I'm pasting it below unexpurgated. [I attribute the lapse into 80's wares talk to the time period. Oh well.] :)

I also found the RWTS and IOB files mentioned, but the crack of side 1 I apparently did was no where to be found. But, maybe this info will be useful to someone who wants to play around with the .nib images. If you want the RWTS and IOB, just email me. Maybe I never got around to posting this to a BBS back then. I don't remember. Better late than never I suppose...

---------------

03/24/87
Notes For Cracking Realms of Darkness

Somewhere in the midwest....

This is side 1 of 3 of Realms of Darkness. Sides 2 and 3 were not completed due to lack of interest and time. These notes are provided just in case someone is in a bad mood and is into self-abuse by cracking worthless wares. They are in no specfic order. None whatsoever. Really.

The boot is pretty tame. $801 uses the controller card to read the RWTS into $9000-$97FF and then uses it to read into $900 then goes to $900 for the rest of the boot, etc.

The protection scheme uses a mixture of 16 and 18 sector formatting which is certainly a thrill. Side 1 happens to have room for spreading out the extra sectors, which is why it's done.

One side 1 you will find tracks 1, 2, 12, and 22 (all numbers are in hex by the way) blank, as in non-formatted. Tracks 3-8 and 13-18 are normal 3.3.
Tracks 9-11 and 19-21 are 18 sector tracks. They contain one long sync byte field and use four byte headers for the sectors. Side 1 uses D6 D5 xx yy, where xx is the sector number and yy is the track number. These two numbers are obtained from the write translate table using the real sector and track numbers as offsets. Sides 2 and 3 use D7 D5 xx yy and D9 D5 xx yy respectively. And both sides 2 and 3 have tracks 0, 2, 3, and 8 normal with the rest of the tracks being 18 sector tracks. And track 1 is blank for sides 2 and 3.

Anyway, the RWTS is called with the following method:

LDX #$hi byte of buffer
LDA #$table code
JSR $9000

The hi byte of the buffer is where the code is to be loaded into and the table code points to the data table for the 18 sector tracks which will be discussed later.

Here are some useful addresses in the RWTS. It contains both normal 3.3 routines and the 18 sector read routine.

$9000-9014 entry pointers
$9016-17 address of where to put the data
$9018 sector sought
$9019 track sought
$901A data table sought and/or in use
$901B first marker (D6, D7, or D9)
$901D slot
$901E data table currently stored (at $8F00 by the way)
$9021 last track accessed

The other addresses in this range are used but who cares.

$9022 normal write routine
$90B5 post nibble routine
$90CD normal read routine
$9135 normal read address routine
$9191 seekabs routine (that's find track to you and me)
$9200 arm delay
$9229 beginning of write translate table
$9270 prenibble routine
$9296 beginning of read translate table
$9300-$9455 buffer
$9456 start of dos
$91F0 sector skew table
$9269-926F scratch
$9563 18 sector read routine
$9456 normal read
$945A normal write
$9461 18 sector read

These last 3 address are the entry points for the described functions.

$91EE is a flag for reading/writing. 1 = read, 2 = write.
$91EF is a flag for using normal or 18 sector. 0 = normal, 1 = 18.
$700 scratch data buffer

The general scheme is to call the RWTS with a couple pointers, it figures out which dos to use and then does it. The nice thing is that there are no 18 sector write routines to mess with and normal dos is available for use in a conversion. The idea behind a crack would be to arrange the data so that the normal dos can be used all the time. This would involve changing the way the flags are set up and the track tables.

Here's a brief description of the track tables. On side 1 they are located on tracks 9 and 19, both sector 0. The data is grouped 3 bytes at a time, arranged as track, sector and byte offset. When the RWTS is called, the accumulator holds the pointer to the data set wanted. The RWTS then multiplies the pointer by 3 and gets the 3 bytes, plus the next 3 bytes. Then it loads in the data starting at the first group until it reaches the beginning of the second group. This requires that the data be laid out in order on the disk--no jumping around to scattered free sectors. It's almost as if they used a conversion program to take all their files and write them end to end. That's why an offset byte is used. One chunk of data could start at byte 3F in one sector and end at byte D2, 5 sectors later. Anyway, the data tables for sides 2 and 3 are on tracks 4, 9, 17, and 1E, all sector 0. In fact, they need to always be sector 0 unless you want to go and change a ton of code. The actual track sector pointers can be modified to whatever you like without the RWTS knowing it. You must disable the flag to use the 18 sector read routine so that it always uses the normal read routine. This is easily done in the code after $9461.

To get all the data you can do a few things. First, copy all the normal tracks onto a blank disk. Then, using either Advanced Demuffin or your own program or by hand, use their RWTS to read the 18 sector tracks. If you use Advanced Demuffin you'll only be getting the first 16 sectors of each track, so you may as well do it by hand. But this can be useful for just getting a peek at the code. So to aid you, an IOB and RWTS module should be tagging along with this file. Load the RWTS module into $9000.

The problem with finishing this cracks lies in the fact that sides 2 and 3 contain more data than can be put back onto the same side of a 16 sector disk. The options therefore are to either move some of the data to extra disks, use 40 tracks, use a packer/unpacker that recreates the original 18 sector format, remove some of the data completely, or just don't bother to do anything.

Well, this is the end of the notes that were obtained in the evening that was spent looking at this program. Don't waste too much of your time.

[BLuRry]

That's a pretty good summary -- but I wonder if the game is worth the effort?

It doesn't look terribly enjoyable: http://www.mobygames.com/game/realms-of-darkness/screenshots ... Maybe I've gotten the wrong impression of it though.

Putting those reservations aside, would it be easier to replace the RWTS with a 800kb disk RWTS and make a 2mg image of it?

-B

[Hot Rod]

On Wednesday, September 26, 2012 12:45:15 AM UTC-5, BLuRry wrote:
> That's a pretty good summary -- but I wonder if the game is worth the effort?
>

Evidently, I didn't think it was worth the effort back then...
But doing it now would at least enable creating physical disks if someone wanted to play it on a real system. Not a project I'll be doing though!

>
>
> It doesn't look terribly enjoyable: http://www.mobygames.com/game/realms-of-darkness/screenshots ... Maybe I've gotten the wrong impression of it though.
>

The .nibs that are up on Asimov are playable in an emulator (I think - it at least boots).

>
>
> Putting those reservations aside, would it be easier to replace the RWTS with a 800kb disk RWTS and make a 2mg image of it?
>

And then be able to create a 3.5" disk? Dunno.

Some more study of the program might find usable room on sides 2 and 3, or create self-extracting versions (they boot with a util that can create a new disk). Just a lot of work.

[Antoine Vignau]

Just checked... i have the nib images only...
Av

[Hot Rod]

On Thursday, September 27, 2012 3:35:24 AM UTC-5, Antoine Vignau wrote:
> Just checked... i have the nib images only...
>
> Av

Sounds like a project for LoGo...

:)

[Antoine Vignau]

Ah ah LOL :-)
I do not think so, I have such a project for Mandragore, programmed by Emile and protected by The Softman (understand the same person).

The softman was among the best pirate in the Apple II world like JPL, Aldo Reset, Laurent Rueil and Chip Select. The kind of guys who spoke LSS fluenty.

Mandragore is probably the most protected software of the Apple II world. Side one has all off-disk protections (stack, etc.) and on-disk ones (4*4, spiralling, etc.) and side two is a 18-sec side.

I met the cracker of it in 2010 (Chip Select), he told me he cracked it in two days. The longest part behind compressing side B to make it hold on a 16-sec side. Pfew... If I count well, I have both complete sides for close to two years now and I still have not worked on the 16-sec version.

Emile: I hate you :-)

Antoine

[roughana]

On Tuesday, 25 September 2012, Hot Rod wrote:
>The problem with finishing this cracks lies in the fact that sides 2 and 3 contain more data than can be >put back onto the same side of a 16 sector disk. The options therefore are to either move some of the >data to extra disks, use 40 tracks, use a packer/unpacker that recreates the original 18 sector format, >remove some of the data completely

One thought crossed my mind on the 18 sector stuff based on my experience with Last Ninja, perhaps some sectors are duplicated, in which case you can reduce the amount of data to store by eliminating that.

I will have to write up my Last Ninja effort one of these days: double sided 18 sector into double sided 16 sector. That was my highest achievement and required a custom RWTS.

On Friday, September 28, 2012 6:05:47 AM UTC+10, Antoine Vignau wrote:

> I have such a project for Mandragore, programmed by Emile and protected by The Softman (understand the same person).

That sounds very interesting. Do you have an original disk that you can bit copy and send to me?

Regards,
Andrew

[Antoine Vignau]

Andrew,
i've never been able to make a working nibble image of it (but i have raw 6*2 bytes of it)
antoine