Re: Realms of Darkness

[BLuRry <brendan.robert@gmail.com>]

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

On Monday, September 24, 2012 7:59:07 PM UTC-5, Hot Rod wrote:
> On Monday, September 24, 2012 11:24:15 AM UTC-5, Hot Rod wrote:
> 
> > 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
> 
> 
> 
> 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.