fpga pdp-10 status report
David G. Conroy
micromachine simulator, which believes that consoles look like
16c450 UARTS, and disks have ATA-2 interfaces.
Fixing ITS to understand a different kind of terminal
and disk was easy. Fixing ITS to understand a model of machine which
was like a KS, but not exactly a KS, was fairly easy too (once
I clued into the fact that "IFE KA10P" really means "IFN KL10P\KS10P").
Finding the microcode bug which caused translation buffer
misses on writes to replay incorrectly sometimes (a joy to find; poke
at the offending location with DDT and the crash goes away because
DDT took the miss on a read), and finding the microcode typo
which caused byte pointers to be read/written controlled by bit 11 of
XCTR rather than bit 10, took a lot longer.
And there are still problems. LOCK crashed the system with
what looked like a stack overflow/underflow trap, which is tomorrow's
debugging.
But at this point I think I believe the architecture of
the machine is sound, and it's time to finish designing and then
build the hardware version of things.
dgc
jmfb...@aol.com
"David G. Conroy" <d...@spies.com> wrote:
>Tonight I logged into an ITS, running on the
>micromachine simulator, which believes that consoles look like
>16c450 UARTS, and disks have ATA-2 interfaces.
>
>Fixing ITS to understand a different kind of terminal
>and disk was easy. Fixing ITS to understand a model of machine which
>was like a KS, but not exactly a KS, was fairly easy too (once
>I clued into the fact that "IFE KA10P" really means "IFN KL10P\KS10P").
Heh, heh. Those pesky macroes.
>
>Finding the microcode bug which caused translation buffer
>misses on writes to replay incorrectly sometimes (a joy to find; poke
>at the offending location with DDT and the crash goes away because
>DDT took the miss on a read),
Would SET ADDRESS BREAK have helped here? You might think about
writing one.
> .. and finding the microcode typo
>which caused byte pointers to be read/written controlled by bit 11 of
>XCTR rather than bit 10, took a lot longer.
I hope you didn't bang your head too much.
>
>And there are still problems. LOCK crashed the system with
>what looked like a stack overflow/underflow trap, which is tomorrow's
>debugging.
>
>But at this point I think I believe the architecture of
>the machine is sound, and it's time to finish designing and then
>build the hardware version of things.
Sounds like you're having fun.
/BAH
Subtract a hundred and four for e-mail.
David G. Conroy
>> misses on writes to replay incorrectly sometimes (a joy to find; poke
>> at the offending location with DDT and the crash goes away because
>> DDT took the miss on a read),
>
> Would SET ADDRESS BREAK have helped here? You might think about
> writing one.
I suspect not. The bug didn't cause the program to
quietly do the wrong thing; the bug caused the micromachine to get
lost in the weeds (it replayed the reference incorrectly after the
translation buffer miss), and then stumble back into the fetch flow and
begin executing instructions "normally" again.
>
>> .. and finding the microcode typo
>> which caused byte pointers to be read/written controlled by bit 11 of
>> XCTR rather than bit 10, took a lot longer.
>
> I hope you didn't bang your head too much.
Only a couple of hours. If the ascii string which was
being manipulated in this case had started with an ordinary character
and the system had typed "AAAAAA..." I would have found it
instantly. But it began with a device-independent cursor control
code (a ^P), and the command interpreter died cleanly with an I/O error of
the type "illegal cursor control sequence" (^P^P).
Charles Richmond
>
> In article <B99D96B1.1C5%d...@spies.com>,
> "David G. Conroy" <d...@spies.com> wrote:
> >Tonight I logged into an ITS, running on the
> >micromachine simulator, which believes that consoles look like
> >16c450 UARTS, and disks have ATA-2 interfaces.
> >
> >Fixing ITS to understand a different kind of terminal
> >and disk was easy. Fixing ITS to understand a model of machine which
> >was like a KS, but not exactly a KS, was fairly easy too (once
> >I clued into the fact that "IFE KA10P" really means "IFN KL10P\KS10P").
>
> Heh, heh. Those pesky macroes.
>
to beat the hell out of them??? I read in _The Soul of a New
Machine_ about such test suites that were used on the MV-8000
at Data General. These programs loop back and forth, execute
all kinds of instructions in many, many combinations, and
generally do everything they can to expose a flaw in the
hardware. Something like this for the -10 would be helpful
to all the fpga developers out there building their own -10.
IMHO.
Did such programs ever exist at DEC???
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
David G. Conroy
for the instructions it implements (AA-AM, CA-CB) which caught a few
errors. Finding the two errors I mentioned would require
a fairly exhaustive diagnostic which ran with paging enabled. There are no
DEC diagnostics which can run with ITS paging enabled, and the
diagnostic I wrote from scratch to take a quick swish around the ITS
executive mode instructions was far from exhaustive.
jmfb...@aol.com
Charles Richmond <rich...@ev1.net> wrote:
>jmfb...@aol.com wrote:
>>
>> In article <B99D96B1.1C5%d...@spies.com>,
>> "David G. Conroy" <d...@spies.com> wrote:
>> >Tonight I logged into an ITS, running on the
>> >micromachine simulator, which believes that consoles look like
>> >16c450 UARTS, and disks have ATA-2 interfaces.
>> >
>> >Fixing ITS to understand a different kind of terminal
>> >and disk was easy. Fixing ITS to understand a model of machine which
>> >was like a KS, but not exactly a KS, was fairly easy too (once
>> >I clued into the fact that "IFE KA10P" really means "IFN KL10P\KS10P").
>>
>> Heh, heh. Those pesky macroes.
>>
>BAH, were there any "test suites" that DEC ran on the -10's
>to beat the hell out of them???
A group got paid to do this. The only people in that group
who actually did any useful work didn't stay long. To
compensate for the lack of testing out of this group, we found
that the Tuesday builds of the monitor gave the system a
pretty good workout (I can't say that this exercised the
hardware--it sure exercised the montior software).
We always wanted ORNL for our field test site because they
had a lot of "users" who did all kinds of different things.
I've quoted the users because a lot of them thought they
were using the IBM machines.
> .. I read in _The Soul of a New
>Machine_ about such test suites that were used on the MV-8000
>at Data General. These programs loop back and forth, execute
>all kinds of instructions in many, many combinations, and
>generally do everything they can to expose a flaw in the
>hardware. Something like this for the -10 would be helpful
>to all the fpga developers out there building their own -10.
>IMHO.
That was supposed to be provided with the diagnostics.
Unfortunately, the diagnostic mind set was based on a hardware
p.o.v. and not a software p.o.v. (this is my hypothesis). The
last guy in charge of the dianostic group did try to add as
many lapses as he could into the diags.
The problem with diags is that they were targeted at _pieces_
of hardware, not the interaction of different kinds of hardware.
>Did such programs ever exist at DEC???
>
Yup. TOPS-10.
glen herrmannsfeldt
<jmfb...@aol.com> wrote in message news:alfcl8$mct$5...@bob.news.rcn.net...
(snip)
> > .. I read in _The Soul of a New
> >Machine_ about such test suites that were used on the MV-8000
> >at Data General. These programs loop back and forth, execute
> >all kinds of instructions in many, many combinations, and
> >generally do everything they can to expose a flaw in the
> >hardware. Something like this for the -10 would be helpful
> >to all the fpga developers out there building their own -10.
> >IMHO.
(snip)
> >Did such programs ever exist at DEC???
> >
> Yup. TOPS-10.
I have some IBM RAM that with a sticker claiming to be OS/2
compatible. It seems that IBM uses a similar system.
-- glen