Looking for POS D.x Pascal source
Josh Dersch
POS Pascal sources for earlier versions of POS?
I'm still (slowly) making progress with my PERQ emulator; this has been
aided greatly by finding POS D.6 microcode sources (incl. QCode
interpreter source) on my PERQ1A's hard drive (which you can find at
http://yahozna.dhs.org/computers/software/PERQ/, should you be so
inclined). Unfortunately, my PERQ only has copies of the microcode
source for D.6, no Pascal source.
I've got the emulator booting from an image of my 1A's hard disk and
progressing to DDS 371, unfortunately the lack of POS Pascal source
matching the microcode source makes the going from here quite slow --
I'm not even sure what DDS 371 indicates for POS D.6.
Thanks in advance...
Josh
Chris Burton
<ders...@pilot.msu.edu> writes
sometimes!). I have to admit that I didn't know that any of the Pascal
sources were available.
DDS 371 meant 'LocateDskHeads entered; buffers allocated' in the 1981
version which I think was POS D.x. The R.2 version means 'Moving disk
heads to Track 0', which I guess is similar.
Bye,
--
Christopher P Burton - A member of the Computer Conservation Society in the UK
skeezics
> This is probably a bit of a long-shot, but does anyone out there have
> POS Pascal sources for earlier versions of POS?
Bitsavers has at least one version of the compiler, in source.
According to:
http://www.bitsavers.org/bits/PERQ/floppy/pos/pascalSrc/labels.txt
pascalSrc1.dmk 610360-02 POS V9.10
Contents: PASCAL COMPILER SOURCE #1 OF 2
pascalSrc2.dmk 610370-02 POS V9.10
Contents: MORE PASCAL COMPILER SOURCE #2 of 2
I think V9.10 is from the POS F or G era, so there are surely some
differences in the Qcode defs between D, F, and G... I think I have (or
had) V9.12g for POS G.6, or Accent? I can't remember...
But this could still be useful if you can unpack the .dmk images and
pull the original files out. As you're probably already aware, the
non-filesystem, regular old "data" floppies on the PERQ were originally
formatted to be RT-11 compatible, so there should be ample references
available for figuring out the layout of the raw image... It has been
so long now - 25 years!? - that I can't recall how things changed on
the PERQ from D.6 and "PLX" to F and G with "FLOPPY" - I vaguely recall
that there was some difference but I don't remember what it was...
since you figured out the POS filesystem layout, RT-11 ought to be a
piece o' cake. :-)
> I'm still (slowly) making progress with my PERQ emulator; this has been
> aided greatly by finding POS D.6 microcode sources (incl. QCode
> interpreter source) on my PERQ1A's hard drive (which you can find at
> http://yahozna.dhs.org/computers/software/PERQ/, should you be so
> inclined). Unfortunately, my PERQ only has copies of the microcode
> source for D.6, no Pascal source.
That's so cool. :-)
Also on bitsavers, the document PERQ_SysSWRefManual_Feb1982.pdf is the
POS D.6 reference, including the fault dictionary. I recently dug up
some more manuals (including a pristine copy of the POS G.5/G.6 manual,
the "C" compiler stuff, even some Qnix info?) and things that might be
of interest - I'll have to get off my backside and box some things up
for Al. :-)
> I've got the emulator booting from an image of my 1A's hard disk and
> progressing to DDS 371, unfortunately the lack of POS Pascal source
> matching the microcode source makes the going from here quite slow --
> I'm not even sure what DDS 371 indicates for POS D.6.
Actually, the code that may shed light is DDS 373 - the next one in
sequence. A 371 ("LocateDskHeads entered, buffers allocated.") implies
a successful completion of the initial memory setup (likely locking
down buffers for DMA?) needed for the upcoming disk operation. Next
you should see 373: "Disk heads at cylinder 0 or disk broken" or a 374:
"Disk heads at cylinder 0 (not broken)".
This section from 370-379 is after the Z80 has been initialized and the
microcode is now using the Z80 to assist in disk seeks, rather than
doing it on the CPU. Have you already got the whole Z80 subsystem into
the emulator? If the emulator goes off into the weeds after you see
371, it's likely that something between the ucode and the Z80 went
awry. Just a guess...
Hope this helps... I really, really wish I had even one working PERQ at
the moment... two bad IOBs and one bad MEM board has me profoundly
depressed that maybe I've neglected them for too long. But I know a
guy who owns and operates a custom PCB assembly business, and have been
thinkin'... :-) Anyone interested in a ridiculously expensive small
run of reverse-engineered original PERQ board sets? Heh. While it'd
be cool to implement a PERQ _hardware_ emulator in a handful of FPGAs
or something, doing it all "in the original TTL" could be fun. More
"authentic"...
-- Chris
Al _Kossow
> I'll have to get off my backside and box some things up
> for Al. :-)
I had planned on coming to Portland, but things got crazy the past
couple of months.
> Hope this helps... I really, really wish I had even one working PERQ at
> the moment... two bad IOBs and one bad MEM board has me profoundly
> depressed
I'll see about packing up my 1A set to loan you.
Without a monitor or keyboard, I'm unlikely to do anything with them in
the near term.
--
Posted via a free Usenet account from http://www.teranews.com
Josh Dersch
> According to:
>
> http://www.bitsavers.org/bits/PERQ/floppy/pos/pascalSrc/labels.txt
>
> pascalSrc1.dmk 610360-02 POS V9.10
> Contents: PASCAL COMPILER SOURCE #1 OF 2
> pascalSrc2.dmk 610370-02 POS V9.10
> Contents: MORE PASCAL COMPILER SOURCE #2 of 2
>
> I think V9.10 is from the POS F or G era, so there are surely some
> differences in the Qcode defs between D, F, and G... I think I have (or
> had) V9.12g for POS G.6, or Accent? I can't remember...
>
> But this could still be useful if you can unpack the .dmk images and
> pull the original files out.
Yes -- I've been meaning to extend my PERQdisk utility to handle floppy
images. If I recall correctly from the POS documentation, the
filesystem layout is pretty much identical to that of a hard disk, with
a few exceptions (the major one being that for a floppy, 4 physical
sectors are mapped to 1 logical sector so that sector sizes are 512
bytes, same as the hard disk.) When I do, I'll let you know what these
images contain. Need to scrounge up some documentation for the .dmk format.
> since you figured out the POS filesystem layout, RT-11 ought to be a
> piece o' cake. :-)
Well, the POS documentation made this very easy :). The whole
filesystem structure is well documented, otherwise it would have taken a
lot longer (if I ever managed to figure it out at all...)
>>> I'm still (slowly) making progress with my PERQ emulator; this has been
>>> aided greatly by finding POS D.6 microcode sources (incl. QCode
>>> interpreter source) on my PERQ1A's hard drive (which you can find at
>>> http://yahozna.dhs.org/computers/software/PERQ/, should you be so
>>> inclined). Unfortunately, my PERQ only has copies of the microcode
>>> source for D.6, no Pascal source.
>>
>> That's so cool. :-)
Yeah -- I was very happy to find it, and I almost overlooked it. It's
been a great resource for figuring out the hardware thus far. If anyone
tried to access the code via the URL above in the past few days, you
probably found that it was down -- there was a major power outage here
in the Seattle area, and my power was out for ~36 hours. Since my
website is hosted on my DSL connection, the power outage took the site
down. It should be back up now. And now my apartment is warm again! :)
>> Also on bitsavers, the document PERQ_SysSWRefManual_Feb1982.pdf is the
>> POS D.6 reference, including the fault dictionary. I recently dug up
>> some more manuals (including a pristine copy of the POS G.5/G.6 manual,
>> the "C" compiler stuff, even some Qnix info?) and things that might be
>> of interest - I'll have to get off my backside and box some things up
>> for Al. :-)
Thanks for pointing that out -- I have a 3-ring-bound hardcopy of the
POS G.2 manuals (06 Apr 83) that came with my 1A and for some reason I
thought they were from approximately the same timeframe as the bitsavers
PDFs so I didn't even think of checking the bitsavers resources. (No, I
have no idea why my PERQ has D.6 installed but came with a G.2 manual.)
And yes -- get that stuff to Al, I'd love to read it someday :).
>>> I've got the emulator booting from an image of my 1A's hard disk and
>>> progressing to DDS 371, unfortunately the lack of POS Pascal source
>>> matching the microcode source makes the going from here quite slow --
>>> I'm not even sure what DDS 371 indicates for POS D.6.
>>
>> Actually, the code that may shed light is DDS 373 - the next one in
>> sequence. A 371 ("LocateDskHeads entered, buffers allocated.") implies
>> a successful completion of the initial memory setup (likely locking
>> down buffers for DMA?) needed for the upcoming disk operation. Next
>> you should see 373: "Disk heads at cylinder 0 or disk broken" or a 374:
>> "Disk heads at cylinder 0 (not broken)".
Thanks for the information (as well as to Chris Burton for providing the
same info in an earlier post). This may be sufficient information to
continue -- I'll see if the POS sources I have have similar code for
LocateDskHeads and see what it is they're looking for. I'm guessing
they're looking for a certain hard drive status register to be set/unset
before continuing. I've worked out a certain portion of how the Hard
Drive controller works thanks to the POS microcode (enough to get to
371) but I'm sure I'm missing a lot of information. (And I have next to
no information about how the Video hardware works -- there are 8 bits in
the video control register which I have no information on...)
What I really need to do is write a better QCode disassembler so I can
more easily follow the Pascal code. And about 100 other things to make
debugging easier. Sigh...
>> This section from 370-379 is after the Z80 has been initialized and the
>> microcode is now using the Z80 to assist in disk seeks, rather than
>> doing it on the CPU. Have you already got the whole Z80 subsystem into
>> the emulator? If the emulator goes off into the weeds after you see
>> 371, it's likely that something between the ucode and the Z80 went
>> awry. Just a guess...
What I have is a "reasonable facsimile" of the Z80 system. I'm not
actually emulating the Z80 or running any Z80 code. For the PERQ 1 this
is sufficient since no user code can run on the Z80. It makes my life a
lot easier, all I had to work out was the messaging protocol used to
communicate between the PERQ CPU and the Z80 and emulate the overall
behavior. (Interesting note: there are two different Z80 protocols, one
used by the original IOB, and a new (much better designed) one for the
CIO/EIO/NIO boards in PERQ2's) Eventually I want to get an authentic
Z80 emulation in there (so I can do a PERQ 2 emulation) but that would
require a ton of work so it's not a high priority at the moment...
>> Hope this helps... I really, really wish I had even one working PERQ at
>> the moment... two bad IOBs and one bad MEM board has me profoundly
>> depressed that maybe I've neglected them for too long.
Sorry to hear that -- hope you get one running soon. I consider myself
lucky that mine still works (barring the digitizer puck), and that I was
able to retrieve some very useful information from it... Love your
hardware idea, though an FPGA one would be cool as well :). And someday
there may be an emulation route, for those who want to run POS on their
laptops :).
Josh
Josh Dersch
the IO microcode expects the Shugart hard drive controller to raise an
interrupt to indicate completion of a seek request via the
Cylinder/Sector control register. Makes sense...
Not sure what's going on at DDS 390, the QCode is sitting in a tight
loop waiting for a value to become 0. (It looks like it's trying to
read data from the keyboard's circular buffer, from a cursory
investigation.) Should not be difficult to debug, though.
Thanks again for the suggestions!
Josh