[Coco] running RSDOS games from hard drive?

[Robert Emery]

--- Robert Gault <robert.gault at worldnet.att.net> wrote:
> 
> This typically happens for one of three reasons, 1) the program tramples 
> on the HDBDOS region in low RAM, 2) the program contains its own disk 
> I/O routines, 3) the program hard codes the drive number for disk I/O.

I tried an experiment with PacDude2. I copied it to FD1, also to HD1. I issued
  DRIVEON:DRIVE1:LOADM"PACDUDE2
(it's auto-executing, single 39 gran binary executable)... it starts loading
from HD1, less than a second, then switches to FD1 where it continues to load
and execute.

I then copied the game to HD7 (clue: binary=111) and tried to load it. After
the initial load, both FD's spin and light, the program does not find "itself"
on FD1 (binary=01) and hangs with the drives spinning. -Reset

Now I copy PACDUDE2.BIN to FD3 (binary=11), the back of FD1.
  DRIVE7:LOADM"PACDUDE2
The game finds itself on FD3 and continues to load and execute.

Apparently it is using the last 2 bits of the drive #, (RSDOSes usual limit).
The drive number is not hard coded, but my guess is that it has it's own IO
routines.
 
> Having "HDB-DOS unravelled" is not the answer. You need a disassembly of 
> the game or at least the sections that do disk I/O. What is/are the games?

I believe the PacDude2 source is actually available from Chris Spry's
website... I looked *very briefly* at it many moons ago but had no clue how to
assemble it. I'm sure I still have it somewhere. Also I'd like to add that this
is my favorite Pac game of all time, one of my favorite ways to show off the
CoCo3 to non-coco-nuts!

I will post more issues with specific programs I as discover them... I'm sure
there's some level of interest in getting them all "HD ready". ;-)

Bob


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com