2 Nov
1999
2 Nov
'99
9:08 a.m.
Phantom was a common signal, but it really didn't take long before many
vendors were simply copying the EPROM into memory, with a flipflop that
enable the EPROM simply toggling off when the most significant location in
the EPROM was accessed. That way it didn't matter much whether you had
PHANTOM implemented or not. The EPROM was generally not enabled for a WRITE
to memory, regardless of where it was writing, so copying the EPROM into RAM
was pretty straightforward. The only thing PHANTOM had to do was disable
the RAM board's output buffers, and it was common enough that it generated a
wait-state or two as well, since the EPROMS were pretty slow.
Nowadays, it's really tempting to use an EPROM or Battery-Backed SRAM to
hold the entire CP/M CCP, BDOS, and BIOS, and let the warm boot reload the
CCP from there. That would certainly make the control-c quicker.
Dick
-----Original Message-----
From: allisonp(a)world.std.com <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, November 02, 1999 1:44 PM
Subject: Re: Northstar Horizon
Ah, ever hear of phantom... part of the MDS-A and VDM IO hack was to set
them up to output Phantom, in both cases it was just a jumper required.
The disable was simpler, MDS-A has a rarely used sector interupt enable
latch and the VDM used a bunch of bits for windowshading, something I
considered useless and removed from the board (a few socket level jumpers)
and I had the bit I needed for enable. If they were enabled phantom was
generated, if they were not ram was there.
Allison
> > My solution was far more reasonable. Map it
<VDM1> at 4000h and set a
bit
> > to enable it (small hack). That way it used
no TPA space and was still
> > faster than using a TTY. I later set up one of the NS* controllers
that
> > way for a full 64k space. Of course I had to
write my own drivers but
it
was pretty trivial.
And hack the RAM board to be disabled when the VDM1 is enabled?