Re: New firmware for PseudoDisk / some problems

[dempson@actrix.gen.nz (David Empson)]

Alex Freed <alexf@mirrow.com> wrote:

> It works fine if I start it from the monitor. But not as a part of a boot
> process.
> If I have another disk card in a higher slot, I can do a reset and get to
> basic.
> My card is in the slot 4. I type "C400G" and everything works fine.
> However if I type 4^P or PR #4 or just let it  boot with no other disk
> cards,
> it hangs.
> Must be something stupid. Any ideas, anyone? What is so different between
> C400G and 4-ctrl-P ?

PR#4 (or equivalent) sets the output vector to $C400, then the next
character output (typically the prompt) triggers a call to the code at
$C400.

For a disk controller, it just proceeds to boot from the disk as if you
had done C400G, so the end result is the same.

I assume you have the correct firmware ID bytes (xx 20 xx 00 xx 03) to
be identified as an autostart device.

I also assume you have a reliable method of identifying which slot you
are in (e.g. disable interrupts, call a known RTS instruction in the
monitor, then read the return address off the stack).

The problem is almost certainly as follows:

If you boot your card with PR#n, and the boot block code is trying to
print anything with COUT, then as soon as it outputs a character, COUT
will JMP indirect to the output vector, which is pointing to $Cn00. This
will proceed to boot again, resulting in an infinite loop.

To avoid this, your menu display code must initialize the I/O vectors.
There are monitor routines for this (but I don't have my notes handy and
I can't remember their addresses offhand). An alternative is to call
COUT1 ($FDF0) instead of COUT, to ensure you are outputting to the
screen.

-- 
David Empson
dempson@actrix.gen.nz