[Coladam] running Super Games from HD

Rich Drushel drushel at apk.net
Tue Oct 23 03:14:18 CEST 2012


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"




More information about the Coladam mailing list