[Coladam] running Super Games from HD

Jim Notini jnoti2 at comcast.net
Tue Oct 23 05:11:50 CEST 2012


Rich,

Great stuff Rich! Jim Walters (and maybe his brother Bruce as well) did 
disassemble all the Coleco made ADAM game software/Super Games that were 
programmed specifically to load only from Digital Data Drive and patched 
them to work from Disk. Jim once explained to me the tremendous endeavor 
that it was to disassemle these programs that were each upwards of 128K and 
to find all the Blocks Reads that needed to be rewritten to load from the 
drive booted from as well as to reorganize the blocks of data in a 
contiguous manner seeing as the original code was arranged in groups of 
blocks on the Data Pack to make seeks and access times faster. So basically, 
Jim Walters rearranged the block locations as well as rewrote the block read 
routines, but all this work was done only to make versions of these games 
that would work from Disk and was done about 3 years before ADAM Hard Drives 
became a reality.

The only method that I could come up with to see if they would work with 
EOS-HD on the new IDE/CF Card package was to block copy all the blocks 
(#00-#159) of one of these Super Games to a freshly INITialized EOS 
partition and to the identical block range, #00-159. Then I created a BOOT 
file in Partition 00 from block #00 of said Super Game, set the active 
Partition to the appropriate partition and booted this newly created BOOT 
file. Suffice it to say that it did not work and locked up the system. 
Wishful thinking at it's best as I already had assumed that it would not 
work, but I had to try.

On another note, you mention that you disassembled EOS-HD in order to get it 
to work with your ADAMServe program. Do you still have this disaassembly 
seeing as I ran across a small bug in it that does not allow you to PAGE 
DOWN by using the DOWN ARROW + HOME keystroke when there are more than 26 
files in Partition 00.... unless the PAGE DOWN keystroke is something 
completely different from the standard that File Manager set and was not 
properly documented in the EOS-HD instructions. BTW, the "MORE" signifier 
does display after the 26th file entry so EOS-HD recognizes that there are 
more file in Partition 00, there is just no way to move to the next page of 
files. The only workaround I have come up with is to delete BOOT files that 
I currently do not need so that I can gain access to other BOOT files and if 
I need the deleted BOOT file, then I change back the deleted status of the 
BOOT file with File Manager.

BTW, the other day I figured out how to hack "Temple of the Snow Dragon" to 
work with EOS-HD and ADAM Hard Drives. Two hurdles needed to be overcome:

- the graphics (actually clip-art files) and text description files have to 
be placed exactly as they are on a DDP or 320K Disk version. File "1A" is 
the first of these files and it has to be placed at block #120, then on an 
on exactly in order all the way to file "10" which has to reside on block 
#245. Then you have to remove the instruction in the " start (H) " file that 
" bloads utility ". It ended up being a lot easier than I thought and I 
didn't have to change anything in the 24K main program file " FIRST2 (H) ", 
although I spent way too much time looking through it. Here is the step by 
step that I provided Bob:

1) INITialize a partition on your CF Card with option V in EOS-HD. This will 
make a clean 12K directory.
2) Boot into File Manager and select this freshly INITialized partition and 
choose option I (File Functions)
3) Choose option I (Edit Catalog)
4) UP ARROW to Directory Entry #2 (the Directory Block) and change the IV - 
LENGTH from 12 BLK to 4 BLK. When you do this the V - USED will change to 4 
BLK as well
5) Still in the Directory listing, press DOWN ARROW until you see the " 
BLOCKS LEF T " entry. It should say III - STARTS AT: 13 BLK, you need to 
change this to 5 BLK . Adjust the IV - LENGTH accordingly to 3067 seeing as 
the partition is 3072 BLOCKS long (5+3067=3072). And finally set V - USED: 
to 0 BLK seeing as these are all unused blocks.

NOW YOU ARE READY TO COPY THE "TEMPLE" program that Doug provided to this 
partition.

6) Place the Temple DDP or DISK in the drive and FILE COPY all the files 
listed in the directory listing to this newly prepared partition on the CF 
Card in the exact order that they appear.
7) Bring up the directory listing of the partition that you just copied the 
files to and RENAME the original " start (H) " file to something like " 
start-old (H) ".
8) Copy the " start-noU (H) " file that I sent you to the partition with the 
rest of the Temple program and then RENAME it to " start " with an " H " 
filetype.
9) Make a BOOT file in Partition 0 by copying BLOCK #00 of the Temple DDP or 
Disk to this BOOT file and name it BOOT-Templ or whatever you fancy.

Now you are ready to play...

10) In EOS-HD, select the partition that Temple resides on with option I and 
then use option III to display a listing of all the boot files on partition 
0 and select the BOOT-Templ file.

and away you go!

BTW, the method in step 4 can be used to edit the Directoy size on any 
partition. Tony automatically sets it to create a 12K directory, but you can 
edit this and adjust the LENGTH and USED blocks accordingly.


Jim/NIAD

----- Original Message ----- 
From: "Rich Drushel" <drushel at apk.net>
To: <coladam at adamcon.org>
Sent: Monday, October 22, 2012 8:14 PM
Subject: [Coladam] running Super Games from HD


>
> Wow, so much traffic on the list that I can't find where the bit about 
> this
> was discussed.  However:
>
> Gist of discussion was, people want to play Super Games from a hard drive,
> but since Super Games access raw tape blocks 0-255, rather than named 
> files
> in a directory, there can be no support.  Moreover, someone said that the
> Super Game tapes being end-directory rather than center-directory would be
> a problem.
>
> Well... I will add a qualified "not so fast..."
>
> Part of the nightmare that is the EOS partition on the standard 10 MB
> hard drive, especially volume 0 block 0, is various patches for software
> that accessed raw blocks from tape or disk.  I don't know who did them
> all (I would guess Tony Morehen), because they were already in place when
> I first started working on Mini Winnie HD stuff with Herman Mason and
> George Koczwara in 1991.  The gist of the patches was to put files from
> various applications in unmovable locations, recompute the block offsets
> for the various boot loaders (which was where most of the raw blocks stuff
> was happening), and then NEVER do a SQUEEZE or CRUNCH of volume 0.  The
> HD version of PowerPaint similarly must sit in a defined place, with its
> 64K XRAM requirement redirected to a virtual memory file that also has
> defined block offsets.
>
> When I reverse-engineered HARDDISK (the EOS program loader shell), for
> ADAMserve, one of the things I did was get rid of all the absolute block
> reads and convert them to standard EOS file I/O.  I *THINK* (but it has 
> been
> a long while) that I did something similar for ADAMlink V's boot loader.
>
> In all my patched versions of HARDDISK, the EOS that is loaded traps the
> keypress SHIFT-TAB, and causes that to increment the current HD volume
> (0-9), wrapping back to 0 from 9, and beeping each time.  This was a
> primitive way to boot from one HD volume, then change to another one as
> the default (for software that did not independently have a patch to
> specify the volume number as part of access to device 24 (tape2/HD), such
> as I did put into SmartBASIC 1.x).
>
> There is only convention for limiting EOS to 10 1024-block volumes -- in
> the days of 20 MB HDs, you put 10 MB for EOS and 10 MB for TDOS.  I don't
> recall the format of the volume 0/block 0 partition table, as interpreted
> by HARDDISK; but I do know that the current EOS volume is just one byte in
> a reserved location in EOS, so logically that could support volumes 0-255.
>
> To come back to Super Games on hard drives... the obvious solution to me
> is to insure that you can format an EOS partition to have at least 255
> volumes.  Put one Super Game tape image on its own volume.  (So what if
> 3/4 of it is not used, HD space is cheap, and currently HARDDISK I don't
> think can deal with EOS volumes of arbitrary different sizes).  Put its 
> boot
> block into volume 0, just like the boot block of any app you want to run.
> In HARDDISK, specify the target volume, then BOOT SOFTWARE.  So long as
> the game itself does not do disk I/O by directly manipulating the ADAMnet
> device control block (DCB), but rather uses EOS function calls, it will
> work with the patched EOSes that I know about, or at least the ones that
> I worked on for ADAMserve.  As far as I remember, the ADAMserve EOS can
> catch function calls all the way down to START_READ_1_BLOCK and 
> START_WRITE_
> 1_BLOCK (which is what the games call so that there is background tape
> rewind while the game is playing -- emulated or with a modern HD, it would
> be instantaneous).
>
> If the game is evil and bypasses EOS completely for block I/O, then the
> game would have to be disassembled and patched.  I have never disassembled
> a Super Game, so I don't know how well they were written to keep code and
> data segments separate.  If code is well-isolated and easily-identifiable,
> it may not be such a job to rewrite to use EOS block I/O and then make it
> emulatable.
>
> Doug Slopsema has been inside HARDDISK more recently than me, so I defer
> to his superior knowledge in case of any errors I have made here.
>
> As for end-directory vs. center-directory tape format, this would not
> affect the operation of the Super Game at all if moved to HD.  The only
> reason for center-directory was to minimize rewind for data tapes, since
> presumably you'd be doing writes as well as reads.  Games are read-only
> (except for a high score screen), and you are loading screens one at
> a time and playing straight through, so having everything in order from
> beginning to end is more efficient.  My Dad did a block copy of his 256K
> Donkey Kong Super Game to a 160K disk, and it played fine until he would
> reach the point in the game where access beyond block 159 was required.
> I remember playing this disk myself.
>
> So, the main problem is software, not hardware, at least for any Super 
> Game
> which does not bang bits in the ADAMnet DCBs.
>
> *Dr. D.*
>
>
> -- 
> Richard F. Drushel, Ph.D.            | "They fell:  for Heaven to them no 
> hope
> Department of Biology                |  imparts / Who hear not for the 
> beating
> Case Western Reserve University      |  of their hearts."
> Cleveland, Ohio  44106-7080  U.S.A.  |         -- Edgar Allan Poe, 
> "Al-Aaraaf"
>
>
> _______________________________________________
> Coladam mailing list
> Coladam at adamcon.org
> http://adamcon.org/cgi-bin/mailman/listinfo/coladam
> 




More information about the Coladam mailing list