home build pdp8 emulator
pdp...@gmail.com
built by a simple hobbyist. So I decided to make one.
I always liked blinkinglights. I built several gadgets with
microprocessors and leds
Then I discover front panels. And because of that, I discover PDP8.
But I can not buy one.
You can simulate it, there are wonderful programs, but you need a PC.
I do not want to have one on just to see the blinkinglights.
You can build a sparetimegizmos kit, but the ancient microprocessor is
hard to find. Henk Gooijen built an emulator using a 6809, but it was
too slow. Someone (in http://www.ndmckinney.net/projects/pocket-pdp-8/),
si building one with arduino, but there are no blinkinghlits. There is
pdp8/x, but i think it is beyond a hobbist posibilities.
¿So, would it be possible to emulate it with a Microchip PIC.?
I am working on it. You can see the details in pdp8r.netne.net.
I am using a 18f452, just because that is what I can get. Once I have
advanced in my project, I will try to get something with more I/O
pins.
According to what I have discovered from my work, it can be done. I am
running some small programs (with blinkinglights, you can see my
videos), and the perspectives are good.
I think the emulator will have the speed of a PDP8/S (ok for me), and
my goal is to run FOCAL69.
Now I am using a modifyed version of gray´s simulator, but I have
found some problems in the code, so I am swithching to jones code.
And I have used only about 25% of the code memory of the 18F. I have
lot of space to do improvements.
Cheers
Ric
cjl
> I could not find material in internet, at least not something to be
> built by a simple hobbyist. So I decided to make one.
> I always liked blinkinglights. I built several gadgets with
> microprocessors and leds
> Then I discover front panels. And because of that, I discover PDP8.
> But I can not buy one.
> You can simulate it, there are wonderful programs, but you need a PC.
> I do not want to have one on just to see the blinkinglights.
> You can build a sparetimegizmos kit, but the ancient microprocessor is
> hard to find. Henk Gooijen built an emulator using a 6809, but it was
> si building one with arduino, but there are no blinkinghlits. There is
> pdp8/x, but i think it is beyond a hobbist posibilities.
> ¿So, would it be possible to emulate it with a Microchip PIC.?
> I am working on it. You can see the details in pdp8r.netne.net.
> I am using a 18f452, just because that is what I can get. Once I have
> advanced in my project, I will try to get something with more I/O
> pins.
> According to what I have discovered from my work, it can be done. I am
> running some small programs (with blinkinglights, you can see my
> videos), and the perspectives are good.
> I think the emulator will have the speed of a PDP8/S (ok for me), and
> my goal is to run FOCAL69.
> Now I am using a modifyed version of gray´s simulator, but I have
> found some problems in the code, so I am swithching to jones code.
> And I have used only about 25% of the code memory of the 18F. I have
> lot of space to do improvements.
> Cheers
> Ric
IMHO, wasting time building a project that lacks the potential to be
"useful" is a waste of time. To be a spec useful PDP-8, at least get
all of the following right:
1) Be VERY CERTAIN you understand the model you are wanting to
imitate [emulate? simulate?] and get it totally right. This allows
checking out your work using the prevailing diagnostics that check for
all the -isms used by some clever software [some small part of which I
personally wrote, such as the routine within Kermit-12 that checks for
model-dependancies to indicate what you are runnng on, and
additionally take necessary steps to make it work on that model where
releveant],
2) Get all of the I/O stuff LOCK-STEP 100% compatible! This cannot
be underestimated. Largely the downfall of the 6120-based stuff, such
as the DECmate lies not in the processor, but the sloppily defined I/O
chips foolishly used around it. Remember, hardware that is
99.99999999% compatible with the intended item is 100% INCOMPATIBLE
with the software that depends on the hardware being correct!
3) Get all of the I/O stuff implemented! Merely making sure you get
through step 1) and 2) is still useless. You need a way to get
additional compatibility. There are various ways to get more
utility. Clearly the BEST and BY FAR the most useful is to have a
disk-based peripheral available. Note: It is NOT NECESSARY to be
compatible with existing stuff. In fact, most of the stuff DEC made
doesn't really cut it when emulated. For example, when emulating an
RK05 using solid-state memory, it is plain silly to be compatible when
most of the shortcomings of existing code has to deal with non-
existent seek problems. The OS/8 system handler for this device is
compromised because it had to pass muster as a handler at all. As
such, the code is sub-par due to limitations of OS/8 itself not
allowing all the nuances of this device to be properly handled. Why
emulate the thing when a better device for emulation exists or can be
defined, and in any case made appropriate for the project. Remember,
in terms of truly useful PDP-8 software, the rules are defined here:
Get 1) and 2) and 3) so far in this paragraph totally correct. If
your additional requirements were to not foolishly rule out OS/8, P?S/
8, COS-310, ETOS, etc. all you need is a sanely defined device as all
of these systems can easily be modified to work with a "home-made"
disk device. For example, the SCSI-based CESI controller for a hex-
wide Omnbus is great for emulation, as is the DSD-240. Both devices
have minimal requirements from the software because in essence, the
scheme is a) Setup in memory a command to another processor, b) Tell
the other thing to go do it, c) Set a flag/interrupt on when the
other thing did it and allow the PDP-8 to interrogate the status of
what happened as a result. [Much of the MDC8 from CESI was
conceptually ripped off from the earlier DSD-240, but the former was
done using an on-board micro while the latter was done in all logic.
But the results are efficient code that isn't a burden to any of these
systems. For the most part, all of the relevant software was easily
modified to handle this "foreign" [as in not sold by DEC] device.
If you also want to raise your horizons to include some of the older
software such as the DMS or TSS8, you could implement a DF32 or RF08,
but one is pitiful and the other is merely too small. In their day,
relatively speaking, disk speed was their forte, not reasonable size.
Practical systems needed additional peripherals to make them more than
literally large toys in the PDP-8 sense due to inability to actually
store anything of significence compared to almost anything else that
came later. These early software systems are roped into non-standard
[by the terms of what came later] usage of hardware quirks that was
deemed worthy of abandoning. [The DMS cannot be implemented on
anything newer because it literally depends on a quirk that doesn't
translate to the newer stuff.] Thus, DMS-compatible hardware lies in
the never-was-mainstream ancient portion of the PDP-8's history. When
the people of my era arrived at DEC, their purpose was in essence to
retire all of those projects entirely, and largely they achieved their
goals. Simulating a machine limited to 4K is borderline useless. P?S/
8 runs in a MINIMUM of 4K; it is totally 32K oriented; it just does a
far better job of budgeting and managing memory than OS/8, which
starts at 8K and really only gets mediocre marks regarding disposition
of the more memory you might have. [P?S/8 does an examplary job
dealing with the realistic issues that matter: Even 12K-oriented OS/8
still gets devices DEC actually produced to have mediocre or even poor
handling of these actual devices. To those knowledgable of the true
nature of things, most of the device drivers of OS/8 are compromised.
A few merely involve writing better code; most of that has been
accomplished already. But for some devices, the basic design of OS/8
is so flawed that at best all you get is a bad compromise, such as
RL01/02, to a small extent RK8E/RK8ES/RK05.
The third-party disk peripherals did a far better job; it really
wasn't hard. The third-party companies studied the true requirements
while the DEC-produced devices often were the "leavings" of projects
committed to the PDP-11 world and thus whatever hatched became the
PDP-8 version. Look at the RX02 as an example. In the PDP-11 world,
you can have the dichotomy of a better-performing device requiring
software memory space for the handler in the O/S that OS/8 cannot
provide [but P?S/8 easily can!] compromising the result. A more PDP-8-
oriented approach gets you something that can provide good performance
and no burden on software. It's been done and can be done again.
There really isn't a great need for compatibility in this one area,
just a good design to allow it to work without compromise. Again, you
could come up with something only P?S/8 could handle, but with a
little effort, you can make all software systems happy [other than the
oldest stuff, such as DMS].
There is also a possibility of a compromised device that could make
everyone happy: The original RF08 was so small that it could only be
expanded up from one too-small disk to as many as 4 of them. PDP-12
software was written to take advantage of a superset of this produced
by DEC's CSS to allow up to 8 drives. Still too small, but better.
Since the RF08 uses the traditional I/O definitions and not any of the
supersets used later, there is clearly the possibility to define an
extension that makes it possible to make it truly large. [Note:
PDP-8/i-type extension is that you can decode IOT1, IOT2, IOT4 as not
merely .OR.-able together such as in the teletype interface [where you
MUST DO THIS CORRECTLY!!!] but instead you can decode IOT1 differently
from IOT2 differently from IOT3 differently from IOT4 differently from
IOT5 differently from IOT6 differently from IOT7. On an Omnibus-
oriented version, you also get IOT0. Since that is meaningless on the
original RF08 spec, and the clinical lab-12 software will never apply,
you don't have to use DEC's obscure and limited band-aid approach to
get the RF merely twice is big as too small to be really useful. You
can use the IOT 0 to setup stuff beyond a total compatibility where
power-clr is equivalent to the IOT 0 with an AC contents of 0000. But
aware software could then patch things up to something as big as 4096
times as big! That, as an upper design goal, totally solves all sorts
of problems. However, you still have to be 100% lockstep with the
original software, which includes the notion of simulating cycle-at-a-
time data break DMA including the real-time dynamic update of the WC
and CA registers because the compatible software [including
diagnostics] demands it. Thus, you can get compatibility with all of
the software, but at a cost of both some performance as well as some
tedious details that complicate the design. [This is why the DSD-240
and MDC8 are so much better for a new project; the PDP-8 does not
participate in its own I/O process. It only cares about what happened
before and after, not during. You can handle the actual transfers any
whay you want, etc. But you will forever lose compatibility with the
DMS and TSS8 in the process.
So, clearly I have designed a fork in the road. As someone not
particularly a fan of the earlier and IMO far less sophisticated
software, use something besides DECtape, DF32, and RF08. You will
have a lot less work and a far better result as you abandon
compatibility with those few I suppose will respond to this who praise
this older software [you were few in number then and even fewer now].
In any case, pick something big enough to be useful, simple enough to
program for all of the O/Ses easily modified to accomdate it OR be
lock-step compatible [ast least in subset] with prevailing stuff.
[But the first clause about being big enough trumps the rest of the
sentence!]
4) It has to be fast enough to be useful! Recommended speed is at
least the speed of the original PDP-8 when all is said and done. A
whole lot faster can be accomodated, but curiously "too-fast" issues
exist for some marginal software such as silly FOCAL69 as
distributed. These issues can all be easily patched. Here is an
example of silly:
In FOCAL69, at one point in model discovery, it has been determined
that what you have is/is not:
1) Not a PDP-5
2) Not a PDP-8/s
3) Not a LINC-8
4) Not a PDP-12
Because FOCAL69 is too old to know about anything newer [such as a
PDP-8/e, a, m, f, 6100 or 6120-based micro, etc.] the decision is
coming down to display "PDP-8" which is a copout meaing "I really
don't know, but since the code runs, this is some model I am ignorant
of" OR apparently an -8/i or -8/l, but not sure which of those two.
The code can be excused for ignorance of the future models, but the
present models still don't pass. Here is the silly reason why:
Rick Merrill was ignorant of how one checks for an -8/L specifically:
[Here is how; look at the source code I wrote in Kermit-12 for more
information: On all machines that could still be in the running at
that point, including all of the newer machines, the instruction 7601
clears the accumulator. This is the group III instruction to clear
the AC, and is associated with EAE, whether or not EAE is
implemented. Because the -8/i definitely supports the possibility of
EAE, there is no particulars restriction on executing 7601. Other EAE
instructions are another matter; they become NOPs which doesn't tell
us anything unless we are also attempting to find out if EAE is
available, an entirely different matter. However, on the -8/L,
because EAE is not possible, the designers of this model put in a
strange quirk: If the instruction is a type-III operate, meaning an
EAE-class one, it is inhibited regardless of whether it could have
been innocuous. There does not seem to be a purpose to what they did,
but the point is that they did it! Thus, only on a PDP-8/L does the
instruction 7601 NOT clear the accumulator, thus an easy test to prove
precisely what CPU this is, etc.]
What FOCAL69 actually does is: The CPU is an -8/i only if it is "fast
enough" else it's an -8/L. However, this logic always breaks down for
multiple reasons, all fatal:
a) Few PDP-8/i machines ever were actually tuned to be faster than an
-8/L to show a difference. PDP-8/L specs memory at 1.6 and achieves
it. PDP-8/i spes memory at 1.5, but in the field, it had to be slowed
down to achieve reliability. It is rumored this is a vendor-related
problem. Perhaps others can shed light on it; all I know is that
apparently DEC used a lot of vendors. Sounds like much of what they
got didn't work without slowing it down a bit; the PDP-12 and PDP-8/l
solve the problem realistically by running slowly on paper and in
reality, etc.
b) Here is where it gets really silly: The timing "clock" is the
teletype output speed flag raising and clearing time! Thus, if you
have a slow -8/i, you are an -8/l, but worse, if you use any number of
faster console devices INCLUDING STUFF DEC SOLD FOR THE PDP-8/I, this
timing loop deems it an -8/l. [Try the LA-30 interface for the -8/i,
l, and -12 for example.]
So, clearly, while we encourage speed, certain silly things will break
down due to too-fast CPUs in the limited design scope of people
writing code shortsightedly, etc. [For the record, P?S/8 never cares
about CPU speed; it literally cannot be too fast for this software,
because no program assumes anything about the console or other
potentially "too-fast" interfaces. Other software systems can and
will get into trouble in certain realistic faster models. No
software, other than the FOCAL silliness which is clearly patchable
and actually unimportant, will get into trouble on a machine say 10
times as fast as an actual PDP-8 model DEC produced, etc.]
That's all of the very real requirements that would make any such
project more than a worthless pipe-dream. Beyond this, a few
recommendations:
a) Adding on an additional serial port gets you a lot of
improvement. Having such an interface allows your project to be
supportable. You can then download into the machine software that can
bootstrap your way into having what you want on the disk the way you
need it. This is the way Kermit-12 can get itself up on a machine
with only OS/8 and no other way to communicate with anything.
b) You can then run Kermit-12 itself using the serial port to talk to
a host of other computers off and on-line in terms of transferring
stuff onto the machine. From the humble beginning, one of us can
assist in getting images of worthy stuff to the machine. Remember,
even if you are lock-step compatible with a device doesn't mean you
can get an image of what runs on it onto it!
Alternatively, there are ways to end-run around this requirement: In
the Gizmo project, it should be possible to get a PC to preload stuff
onto a disk then moved to a more PDP-8-like environment. You don't
get to run Kermit, but you do have a somewhat clumsy but functional at
all approach to shoveling around files, etc. Perhaps you could also
implement additional devices that are themselves PC-friendly such as
flash memory; as long as the PDP-8 interface to them can be made
viable enough to allow simple toggle-in of loader programs [you do
intend to have a front panel after all, correct?] then this could
allow getting packets of stuff to the PDP-8 as well.
Please consider all of these steps, and then rethink the scope of what
you are doing. If all you want to do is report what you are playing
with, it's intrinsic interest to all here becomes quite limited and
transient. Don't be afraid to ask for help, clarification,
documentation, and advice; this is a group, not a bunch of totally
isolated individuals.
cjl [writer of literally dozens of PDP-8 drivers over the years]
Robert
wrote:
> [P?S/8 does an examplary job
>dealing with the realistic issues that matter:
But P?S/8 is unavailable, has always been unavailable and will
douibtless continue to be unavailable so why bother about it? DEC OSs
whatever their shortcomings are what matter to classic computers.
cjl
> On Tue, 26 May 2009 20:30:32 -0700 (PDT), cjl <clasyst...@gmail.com>
> wrote:
>
> > [P?S/8 does an examplary job
> >dealing with the realistic issues that matter:
>
> But P?S/8 is unavailable, has always been unavailable and will
> douibtless continue to be unavailable so why bother about it? DEC OSs
> whatever their shortcomings are what matter to classic computers.
You can have your own opinion about "what matters" of course.
However:
1) With regard to my posting, the point is that P?S/8 is the only
system in the list I referenced THAT DOES NOT REQUIRE the lock-step
compatibility. It is far more flexible due to easily-achieved far-
better memory management issues that were never really thought through
in OS/8. Thus, the point is a design can be achieved that would only
be able to run P?S/8 and nothing else. That would not be useful, even
to me. Additionally, since P?S/8 is the only system that
realistically deals with the notion of logical console support, the
vagaries of an *almost* compatible interface doesn't bother it
either;witness the fact that it is the only system to run on not only
all of the PDP-8 models, but also all of the DECmates. OS/8 has to
have a balkanized "family" of systems, each incompatible with the
others, and programs that cannot run on all of them as an unfortunate
result. The people who created this mess had no idea, clue, or care
about backward-compatibility, and the mess that results from this
shortsightedness is what we have now. [You might also remember that I
am one of the proponents of cleaning this mess up by creating a
unified replacement for all of them; it wouldn't be compatible with
any of them exactly, but it would run on anything. If it were the
older hardware, the older programs would run from it, but if they
cannot without rewrite, it wouldn't matter anyway, etc. Thus, it
would appear that given the overall reality, it would seem that OS/8
has become the irrelevant system. Or at least it seems that way if
you happen to be a fan of DECmates, and of course turning the tables
just juxtaposes the players. The point is that had this been handled
better instead of painted into a corner, this wouldn't have even
happened; one could hope that the time not wasted dealing with this
nonsense would have been better spent on bettering the generic aspects
of OS/8, but I feel I am being too optimistic in that.]
Generally speaking with regard to any sort of hardware good enough, if
OS/8 can run on it, P?S/8 can run either equally or better,
depending. In the process, for what both systems offer beyond
configuration considerations, P?S/8 is either the same or better as
well, and in some instances a striking difference; the "shoot-out"
that occurred on DEC premises came to the conclusion [at the hands of
DEC managers who witnessed it] that P?S/8 was better, but they weren't
up for supporting another system. Blame the PDP-11 world for this,
lack of seed money in the PDP-8 world; fortunes were spent on dead-
ends in the -11 world. [One idiot manager even said that since the P?
S/8 minimum configuration was smaller than the OS/8 equivalent, it
would "discourage memory sales".] [Note: The people who observed the
demo and liked it were not in a position to ask for more funding from
green-eyeshade types who had no technical interest in anything other
than bottom-line; they shot it down, not anyone in a position of
technical authority.]
Please note that P?S/8 is the only software that can run on any
machine from a straight -8 through a DECmate II on literally the exact
same media [all configurations need to be carefully chosen, but this
is a true statement. With some work, this can also include the
DECmate III and III+, but only on media that would work on the DECmate
II, III, and III+ .] The best OS/8 can do is require more memory,
something especially hard on the earlier machines [where it is
difficult to get 8K and extremely difficult to get more than 8K. In
the case of the LINC-8, I believe it was never done.] In any case, if
it can run on these difficult or not so difficult PDP-8 configurations
[system device is RX01/RX02/DSD-210], clearly it cannot run on
anything called DECmate. You need to switch to another OS/8 family
variant for those; the DM I is totally apart from what came later and
earlier.
So, you can say what matters for yourself, but I have it at the word
of then-current DEC management that they would have wanted to continue
the support for this system, which I have pointed out was started by
Richard Lary, were it not for monetary considerations, and certainly
not for technical merit considerations.
2) This system was offered to DEC not once, but twice; the first time
as the subject of a proposal, pointing out how much was already
written, the familiarity of it on the part of not only me and the
other people who did not work for DEC, but also at least six others of
the then-current relevant DEC programming groups [the internal
organization of DEC was inconsistent and "fluid" thus I do not want to
use the words "PDP-8 programming group" and also some worked on other
machines as well as PDP-8 during their DEC careers, etc.].
In point of fact, the first version of what became known as COS
actually *was* a slightly fractured version of it, and it *was* in
fact supported. [Of course, they strongly encouraged all to upgrade
to COS 300 then 310, but the innards of this project has its roots in
both the forerunner of P?S/8 *and* OS/8. Curiously, the final COS
version is a sort of mix of the best of P?S/8, OS/8, and even a piece
of Poly Basic.]
The proposal for this first offering was done "on company time" by
members of the programming staff with their managers' collective
blessing. The greeneyeshade people shot it down, but they [not of the
shades] wanted to try again because all in a technical position really
wanted it. At that early time, all parties wanted no money for it,
just a further collection of considerations to the Polytechnic
Institute of Brooklyn, the school being the common thread for all
parties concerned, etc. [There had been a loan of a PDP-12 arranged,
but only for one year; the school had no money to buy anything else.
The only other available DEC hardware was the original one-DECtape 4K
w/EAE straight PDP-8 that Richard Lary and Lenny Elekman started this
whole thing on, wrote Poly Basic from it on, and Spacewar was written
on and for, etc.]
Eventually, after it became obvious that DEC was not going to do
anything for this project, I felt no loyalty to them; why would
anyone? Then came along my deal with Intersil to license the product
under the private-label of IFDOS [Intercept Floppy Disk Operating
System] to run on the hardware of an 8K or more Intersil Intercept I
with the DSD-210 RX01 superset pair of 8" floppies. [The DSD-210 is a
compatible superset of the RX01, although it is not compatible with
the RX8E card. Omnibus interfaces and Intercept bus interfaces
exist. They are 100% compatible programming wise, including all
diagnostics. The differences are a) Using a minimal piece of
programming that will be meaningless on the actual RX01, it implements
a FORMAT TRACK command which allows a trivial viable formatting
program to be written, b) It supports write-protect both from
switches on the front panel and on the foil sensor level of the media;
a user mod of the real RX01 is compatible with this, but it is
defeated from the factory and easily overcome, etc., and c) It
supports a buss capable of supporting 4 drives, not two; standard
packaging is two drives, but alternate front panel metal allows for
either a single drive or three drives in the standard box using the
provided power supply; 4th drive considerations require using an
external box, but the cable can easily be extended past the first box
if required.] If you purchased at least 12K, you could also run OS/8
on the same hardware. [Minor hardware note: I believe the DSD
interface is a perhaps "intelligent" connector conspiracy converter
cable away from total RX8E compatibility. The basics of the interface
are the same, but besides using a different ribbon cable and connector
system with essentially the same signals in it, I would say they
perhaps also changed the analogue aspects of the signals, i.e., used
different and perhaps incompatible line drivers/receivers to allow
reliable operation with longer cables than DEC used, not that what DEC
used was all that bad, just not quite as good.]
When Intersil announced the IM6100, various management types at DEC
didn't like it. Their legal department had some run-ins on some
issues, one aimed personally at me:
a) They correctly pointed out to management that DEC had no case
against Intersil for selling PDP-8 paper-tape software to Intersil's
customers, because they were paying end-user retail for the software
and were not reproducing it, just passing it along. This software was
never bundled and was purchaseable and indeed was purchased, etc.
That Intersil claimed the hardware was compatible [of course it was!]
was not a committment by DEC and they never implied there ever was a
committment, other than the implication that the software was useful
to purchase for their product [which merely implies compatibility, not
DEC support].
b) The greeneyes assumed that since P?S/8 was an operating system,
somehow I must have stolen it from DEC. The technical people all
pointed out to them that it had been offered to them not once, but
twice, and they had rejected it, thus it was DEC's fault they never
bought it from me. After all, they could have paid me a loyalty fee
[as opposed to a royalty fee I exacted from Intersil for IFDOS] to
ensure it couldn't be sold by competitors. [Note: This is NOT a
hindsight argument: This was already past the point where the early
DCC machines were produced that were not only PDP-8 compatible, but at
least one model was actually faster than anything 12-bit DEC ever
made. Had not DG bought the company in settlement of their lawsuit
because of Nova copyright violation and decided to can the 12-bit
product line, DEC might have been pursuing measures against them.
Note: You might want to reference my discussion about the anti-DCC
code in FOCAL-8, arguably the world's first computer virus, and
certainly the first from a manufacturer to sabotege a competitor.]
The only actual DEC software within P?S/8 is the FOCAL69 vast
extensions are mine; FOCAL69 itself is obviously DEC's. However, I
provided the binary of my extensions, the installer aspect of putting
it on an otherwise finished P?S/8 system, and not FOCAL69 itself.
However, P?S/8 is perfectly capable of converting a binary paper-tape
of FOCAL69 into the requisite P?S/8 binary files to complete what is
needed. [Note: No source code was included, but it was documented
what exactly to do; this was a royalty for a running product license,
not a sellout of the software in source form to them to do whatever
they wanted with it. The source code did not require the original,
just to be loaded over the original when assembled. Intersil sold
their customers the hardware, the DEC paper-tapes in original form,
and IFDOS. Thus, following the provided documentation allowed the P?S/
8 FOCAL69 to be created. Note also that P?S/8 is five text characters
and so is IFDOS; it was patched in as necessary. That of course also
included FOCAL cosmetics as necessary.]
Thus, I have to thank a lot of friends within DEC from saving me from
being sued by a company big enough to have "buried me in paper" and a
lot worse, all over a matter they had no business pursuing, and
fortunately was called off.
However, this shows you just how many people thought of P?S/8 as more
than some irrelevancy as you would write it off. That DEC didn't
support it is merely an accident of history, not as intended. Had all
of us had a larger hand in it, it would be far better off than today,
which although a subset of its potential, still has a lot implemented
far better than anything else on the PDP-8 when comparing things that
can be compared. I require OS/8 myself to handle the hopefully
dwindling "gaps" implied by that statement. Please also note that
Richard Lary always intended OS/8 to be a means to an end, and not an
end in itself; it was done too sloppily to want to become the end
product. The greeneyes didn't see it that way of course. [Note: I
find all of these systems are woefully inadequate for "real"
applications I wrote. Most of them were stand-alone systems complete
with utilities; all of the relevant code was ripped off from P?S/8
because it made the most sense, albeit the code was changed to be
incompatible with everything else as the application requirement
warranted. Thus, for some very large applications, even P?S?8 become
nothing more than a development tool.]
As to its availability ever, speak for yourself. There are users out
there who were able to use then-current preliminary versions on
machines where anything else on the configuration would be
preposterous. Remember, this was written at a time when everything
else was literally pathetic and essentially worthless, regardless of
the opinions of those who didn't have to back up that statement.
Contrary to what you may have decided was how the past went down, the
actual facts are that back then a lot of machines weren't up to the
task of seriously using OS/8 or even able to contemplate it at all due
to literal lack of sufficient hardware to either meet the minimum
requirement or if too close to it, dealing with the attendant
overhead. Today, many people are attempting to put PDP-8 machines
together. Would you have them forever have configurations that could
run P?S/8 but not OS/8 and thus run nothing?
I cannot make any promises, but, assuming various issues in my life
[which is a whole lot more important issue with me] can coalesce
properly, the availability you scoff at may yet come about. Also,
please remember that my existence is not a mere "service" to those who
may or may not want to contemplate using something they are largely
unfamiliar with and can only form truly ignorant opinions about. My
committments are my own; I don't ask for any from anyone else, and I
also don't attempt to criticize anyone, other than offer constructive
criticism if I possibly can, etc.
cjl [when life throws you a curve, become a more competent curveball
pitcher and throw it back]
Robert
wrote:
>You can have your own opinion about "what matters" of course
Thanks and of course I do.
I don't doubt P?S/8's capabilities, I'm pointing out only that it was
never available for the pdp8 and has no place on the pdp8 usenet
group. Perhaps there should be an alt.sys.IM6100 where it might have
relevance.
So far as OS/8 is concerned and whatever its shortcomings it was ahead
of anything else commercially available at the time and was in
everyday use in many large environments (my own employer, a large
semiconductor manufacturer ran dozens on the test floor for instance)
giving minimal problems. I don't know of anyone in the industry who
ran equivalent IM6100 setups.
I'm sure I understand your bitterness and frustration with the past
but this group is about pdp8 computers and red herrings such as
compatible-ish hardware and unavailable OSs is a bit of a waste of
time (IMHO of course).
Alun
and the extra work involved in the main instruction
loop will assist in bringing the emulation down to
the 1.2 uSec cycle time from the 20MHz of the PIC ...
(0th step. Only applies if full bus emulation also being
considered - check for outstanding DMA)
1. Check Halt switches, single cycle and single instruction modes.
2. Check for outstanding bank switching (previous instruction space,
previous data space)
3. Check for outstanding enabled interrupt
4. Finally instruction fetch and emulation proper.
I have been following this thread with interest (and am amazed by
the voluminous negativity from an ex-DEC person; perhaps such
negativity contributed to DEC's decline?) as it is something that
has appealed to me since first encountering the PDP-8 in 1969
through a fellow student who was making his own using reject
ICs and then finding the goodish ones by retesting them.
As far as front panels go, I'd intended (as I'm a model engineer
anyway) to go for a quarter-size front panel, and to reproduce the
art work using one of the many drawing packages available.
Problems in locating the exact font would be circumvented by
drawing the lettering as shapes, as there are so few of them anyway.
As a model engineer, I'm also intrigued by the possibility of manufacturing
a quarter-size paper-tape reader-punch except that I've no source for
(even full size) paper tape these days.
Johnny Billquist
> On Wed, 27 May 2009 22:14:14 -0700 (PDT), cjl <clasy...@gmail.com>
> wrote:
>
>> You can have your own opinion about "what matters" of course
>
> Thanks and of course I do.
>
> I don't doubt P?S/8's capabilities, I'm pointing out only that it was
> never available for the pdp8 and has no place on the pdp8 usenet
> group. Perhaps there should be an alt.sys.IM6100 where it might have
> relevance.
I don't get it. This is alt.sys.pdp8, not alt.sys.os8. So anything
pdp8-related would definitely be okay here. So what that you don't have
P?S/8, some people obviously do, and it runs on PDP8s.
> I'm sure I understand your bitterness and frustration with the past
> but this group is about pdp8 computers and red herrings such as
> compatible-ish hardware and unavailable OSs is a bit of a waste of
> time (IMHO of course).
While it might feel frustrating to hear cjl praise a system that only a
few have ever seen or used, I can't see your point of claiming that it
don't belong here. P?S/8 runs perfectly fine on any PDP8. The fact that
is *also* works on PDP8-compatible hardware is hardly a reason to
disqualify it.
Do you also mean that anything DECmate-related don't belong here?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Roger Ivie
> As a model engineer, I'm also intrigued by the possibility of manufacturing
> a quarter-size paper-tape reader-punch except that I've no source for
> (even full size) paper tape these days.
Have you gone down to the sewing section of your local Wal-Mart and
scoped out the ribbons? Seems like some of those might be usable as a
paper-tape-like substance.
--
roger ivie
ri...@ridgenet.net
Robert
wrote:
> I've no source for
> (even full size) paper tape these days.
>
Full size stuff is readily available (and maybe you'd not believe it
but is still in regular use in some machine shops). For instance try
http://www.westnc.com/
Lawrence D'Oliveiro
> On Thu, 28 May 2009 15:01:52 GMT, Roger Ivie <ri...@ridgenet.net>
> wrote:
>
>> I've no source for (even full size) paper tape these days.
No he didn't.
pdp...@gmail.com
Thank you all for your feedback
cjl, I appreciate your comments, and the effort you take to explain me
those facts, I am sorry I can not fullfill your expectations with my
project, but the point is that I am doing this just for fan, it do not
need to be productive. It happens that sometimes I like to watch TV,
or read a book, or ride my bike..., or do some programming in my PDP8
project. It is just some different activitie to get rid of stress and
daily work. It has no other objective.
alun, I am planning to do something like that once I got the thing
running. then I will focus on performance.
I am not going for something complex. My goal is a straight pdp8, 4K
ram, no eae, no memory management, only keyboard/reader, printer/
punch. Keyboard will be a PC one, printer just a LCD panel (even if it
is only 40 columns). dma only if required.
¿can anyone tell me if it will be required to run focal ?
reader/puncher will be simulated with serial eeproms.
It will have blinking lights (that is the main reason), and switches.
Appearence is not important, it do not needs to look like a real one.
I will use just what I can get.
I am not planning full bus emulation. ( I am not planning bus
emulation). Main objective is just to have the device in my office,
with it blinking lights, from time to time changing the focal program,
just to see a different pattern. Eventually, and if the implementation
process is not complex and do not takes a long time, may be i will try
to obtain some kind of bus, just to control my watering garden system.
Then there will be a PDP8 (ok ,a PDP8/R ( I am ric)) running for the
next 30 years. long life to PDP8.
more seriusly, I think that an advantage of my approach, is that it
could be possible to do the modifications that you want or need, and
to add functionalities that never were in the real system.
I am aware that this should be much easier with a more powerfull
microcontroler, like an ARM, but I can not get them (ok, may be buying
them in digikey).
but i do not have the skills to work with the new small packages.
bye and thank you,
ricardo
cjl
> On Wed, 27 May 2009 22:14:14 -0700 (PDT), cjl <clasyst...@gmail.com>
> wrote:
>
> >You can have your own opinion about "what matters" of course
>
> Thanks and of course I do.
Yes, you do, no matter how misguided.
>
> I don't doubt P?S/8's capabilities, I'm pointing out only that it was
> never available for the pdp8
If you read my post, this is direct contradiction to what it says; go
back and re-read it.
> and has no place on the pdp8 usenet
> group.
I would suggest your entire posts have no place on the PDP8 usenet
group, which btw, I personally created, and never have I influenced
[before] anyone else's right to claim what was and was not
appropriate. Rants like that clearly have no business here. This is
not a place for dictators.
We don't even have a restriction on commerical products on this group,
and certainly nothing here resembles a pitch for one, so I seriously
suggest you rethink and take back what you just posted.
Perhaps there should be an alt.sys.IM6100 where it might have
> relevance.
Not only is that totally from outer space, it implies you don't
understand just exactly what the purpose of this group is; I suggest
you rethink that as well.
>
> So far as OS/8 is concerned and whatever its shortcomings it was ahead
> of anything else commercially available at the time and was in
> everyday use in many large environments (my own employer, a large
> semiconductor manufacturer ran dozens on the test floor for instance)
> giving minimal problems. I don't know of anyone in the industry who
> ran equivalent IM6100 setups.
That you keep mentioning IM6100 as if that is even relevant [I
mentioned not anything other than the fact that Intersil sold a
machine based on it; so did DEC, the VT-78, a totally appropriate
topic of this group, and something already covered here; so did
others; so did a lot of people who posted here home-brew them. Not to
mention the 6120, its direct descendent, used in DECmates, a CESI CPU
board for the Omnibus, and the Gizmo; all of these are absolutely
mainstream topics of this group; your arrogance on dictating in your
ignorance what you do not like is disappointing; please take it
somewhere else.]
>
> I'm sure I understand your bitterness and frustration with the past
> but this group is about pdp8 computers and red herrings such as
> compatible-ish hardware and unavailable OSs is a bit of a waste of
> time (IMHO of course).
Since your opinion is based on patently wrong data, assumptions and
implications, IMHO take it elsewhere. I don't have bitterness or
frustration, just experience with what you are merely badly guessing
at. You never had a relationship with DEC; I did, and it wasn't
always a rosy one, so what.
cjl [stop making me contribute to the waste of bandwidth you started
with your lunatic notions.]
cjl
> The proposal to emulate using a PIC is a good one,
> and the extra work involved in the main instruction
> loop will assist in bringing the emulation down to
> the 1.2 uSec cycle time from the 20MHz of the PIC ...
>
> (0th step. Only applies if full bus emulation also being
> considered - check for outstanding DMA)
>
> 1. Check Halt switches, single cycle and single instruction modes.
>
> 2. Check for outstanding bank switching (previous instruction space,
> previous data space)
>
> 3. Check for outstanding enabled interrupt
>
> 4. Finally instruction fetch and emulation proper.
>
> I have been following this thread with interest (and am amazed by
> the voluminous negativity from an ex-DEC person; perhaps such
> negativity contributed to DEC's decline?)
The so-called negativity I will assume is attributed to me. Read what
was posted and my response to it. It is all reactionary, not
initiated.
DEC's decline had little to do with the issues raised here; for that,
look in the back pages of alt.folklore.computer.
I guess you also didn't quite read the post you apparently reference,
because it clearly states I never was a DEC employee, thus, there
isn't any ex-DEC person in any current thread I am aware of; please
enlighten me if I am mistaken.
cjl
cjl
> Hi.
>
> Thank you all for your feedback
>
> cjl, I appreciate your comments, and the effort you take to explain me
> those facts, I am sorry I can not fullfill your expectations with my
> project, but the point is that I am doing this just for fan, it do not
> need to be productive. It happens that sometimes I like to watch TV,
> or read a book, or ride my bike..., or do some programming in my PDP8
> project. It is just some different activitie to get rid of stress and
> daily work. It has no other objective.
That's OK. As long as you understand where the potential upgrades fit
in, perhaps you will rethink it in the future. And of course, this
can be some food-for-thought also for others.
There are no "rules" here per se. Toys are cute; so are bigger toys.
Read Doug Jones' work on why people do PDP-8-type stuff; there is room
for all of us here, etc.
In any case, I am available somewhat to help people out on some of the
"stickier" nuances on just what needs to be done to satisfy whatever
requirements there are for whatever software compatibility is needed,
if applicable. It's just that depending on what someone wants, the
requirements could be conflicting, etc. It's just part of the overall
PDP-8 history that systems were written to depend on quirks of stuff
that later, you couldn't necessarily get compatible hardware for. As
a student of all of this, and in "real-time" [meaning I did all of
this years ago, back when much of it was unfolding], I strove to make
what I added to the pie be as flexible as possible, something often
overlooked by many of those who wrote code only to find it became
problematic later, etc.
cjl
cjl
Thanks for the voice of reason here.
To clear the air for some of our apparently more ignorant newbies:
Here is the complete list of the differences between the requirements
of P?S/8 versus OS/8 family members.
1) P?S/8 requires 4K; OS/8 requires 8K.
2) Both require lock-step compatibility with DEC console interfaces
and extended memory control considerations.
3) Both can be made to work on all PDP-8 models except for the PDP-8
and the PDP-8/s. This has a name: "The family of -8" made up by some
DEC PDP-8 markateers. They also invented the term "Pre-Omnibus
machines" to delete all machines from the PDP-12 and -8/l backwards to
the PDP-8, but to not exclude anything forwards of that; most
specifically, it includes the VT-78 in the included list, and that is
the only DEC machine based on the IM/HM6100 from Intersil/Harris. It
is inherently part of the "Family of 8"; FOCAL-8 and FOCAL69 work just
fine on it, although as in the case of some other models, it isn't
detected properly. [See Kermit-12 for how to solve that cosmetic
problem.]
4) Some problematic configurations of both systems cannot handle the
basic requirements. The P?S/8 requirement is slightly more stringent
than the OS/8 one because P?S/8 demands slightly more of the system
handler than does OS/8. They both "live" in the same general memory
space, 07600-07777, but OS/8 has a slight advantage because a) Less
things are stored there, yet, absurdly, it has run into trouble with
the likes of date obsolescence; P?S/8 date range starts in 1960 and
covers a range of 139 years past that, so it won't expire until long
after just about all of us will,namely the year 2099. [And using a
subset of the OS/8 type kludges that made it expire in 2001, P?S/8
could be made to last centuries longer.], and b) Some of the things
can be stored in field 1 7600-7777 which P?S/8 cannot use in general.
In the OS/8 case, you must have a minimum of 12K to get any
improvement. However, you don't really get all of the additional 128
words implied [it used x7600-x7777 where x is normally 2, but part of
the spec is that certain OS/8 apps can move the entire field 2 portion
to any higher still field, such as 7]. Part of the problem is that
the handler must reserve kludge words in field 0 that are lock-step
identical with the TD8E specific handler, even if such words are
otherwise irrelevant to the requirements of the system handler. This
is because the apps [F4 and BASIC and a few others] will move the
field 2 stuff to the highest implemented field dynamically [returning
things back to normal after the app finishes just before exiting] and
the apps need to believe their special handling is of a TD8E; the
mechanism to recognize what to do was never upgraded beyond this poor
kludge.
Additionally, because the code exists in two different fields, there
is an implied overhead that wouldn't exist if this were two pages in
the same field. [There is always inter-page overhead, but inter-field
overhead is beyond that.]
Thus, OS/8 has a dichotomy of a memory model: If the system handler
fits all in the first 4K, then you can do what you want with 7600-7777
of any memory field above the first 0 and 1, which are both reserved.
That is, unless you also run OS/8 BATCH which also grabs some of field
2 7600-7777 [and will also be moved by such as F4 and BASIC as
described above]. Thus, it is difficult to plan on the use of x7600-
x7777 for any field greater than 2 or perhaps 3 depending on exactly
what you have. When the system device is the 12K variety, it then
gets modestly dicier; the overall recommendation is to totally avoid
the use of x7600 in ANY field, although one-off situations have been
written for limited application, such as a program that uses
30000-37777 knowing that the machine is at least 20K. [I have written
a few of those myself; I am hardly unique in having to deal with it].
P?S?8 handles the memory allocation problem totally differently:
The basic system requires 4K, but if a handler cannot fit entirely in
07600-07777, it is entitled to use extended memory, thus upping the
basic requirement to 8K. If so, the handler also gets x6000-x7777
where x is definitely the highest field available, thus x is always 1
through 7 as high as possible, etc. So far, OS/8's two-page system
handlers are mostly either slightly limited or downright kludged.
This is because the hardware got progressively "stupider" instead of
"smarter" and had PDP-11-like mindset issues on the part of the
engineers who didn't ask what the PDP-8 really should have had. In
hindsight, OS/8 should have never been limited to at most two pages.
Perhaps this should have been a 16K consideration as a minumum. P?S/8
so far has never even needed all nine of the pages available, but some
have needed as many as 7 [one has an internal two-page buffer to offer
logical support of physical fractions of a sector, analogous to what
some versions of CP/M-80 did.].
Along the way, while 07600-07777 is as off limits to apps as it is in
OS/8, as long as there is more than 8K, the use of x7600-x7777 is
unrestricted, except for the top field. Thus, on a 32K machine, you
can do whatever you want in 10000-67777 the biggest chunk of
contiguous memory. P?S/8 BATCH runs in 4K and does not impact on the
memory model. [Note: OS/8 BATCH is a crock, and others wrote a Batch-
like facility that did not up the memory requirement, but DEC ignored
it to their own peril.]
Along the way, P?S/8 supports a core status word that informs any
inquiring program of:
1) What is the physical size of memory.
2) What is the largest memory available [perhaps limited by the CORE
command, a superset of the OS/8 equivalent].
3) What is the largest size 2) could be set to. This allows program
advisory to definitely get more memory, since the CORE command
artificially lowered what was available; the fault being all you can
get usually. Or to inform the user that it is hopeless should that
apply.
4) The presence of logical console support [see below]
The requirement above with regard to the console interface needs to be
revisited: OS/8 the original system requires the real hardware; so
does P?S/8 except for a few differences [depending].
a) OS/8 sucks when using terminals that demand control-S/control-Q
support. This is because all of OS/8 literally doesn't support it.
There is a KL8E handler, but that is only used when explicitly asked
for as an output device. All other console output throughout the
system by and large does not support it at all. Thus, many people set
the baud rate for their terminals to lower baud rates to LIMIT the
flawed output; it can never be fully remedied, although certain people
don't stumble on it as much as others; it depends on what you run.
Some applications do have "private" control-S/control-Q support
within, but OS/8 itself does not.
P?S/8 scrupulously embraces control-S/control-Q 100% period. Use
scroll keys or control-S/control-Q typing all you want whether your
terminal requires it or not.
b) OS/8 requires the PDP-8 hardware for the console. This hardware
is found on all models of PDP-5 and PDP-8, LINC-8, and PDP-12, and all
Omnibus CPUs, the Gizmo, the VT-78, the Intercept I, and the PCM-12
and PCM-12A [the last two are from Pacific CyberMetrix, who
essentially made a buss-compatible kit form of the Intercept; they
share interface modules and memory modules, but differ in CPU
implementation and mainboard and packaging considerations, but are
clearly of the same class; they both implement front panels in similar
but different ways using control-panel memory and a clock interrupt to
refresh it that can be intrusive, so it can be speed-adjusted with
respect to update rate, etc.]
The Intercept I is the machine sold with IFDOS. I don't recommend
using it, because it is too old. Much better to use OS/8 and/or P?S/8
from a more modern time. I have used both on that hardware.
All DECmates violate this convention, and this is in part why we have
to have OS/78 vX where X means different things depending, as well as
OS/278 perversions that don't even totally work, in part because not
only is the console hardware not compatible, the programmers were
ignorant of the actual differences. [Part of this was a programming
tip/note from one of them to the rest, but it was itself incorrect;
the hardware simply doesn't work the way described. This is in part
why you dare not type LF into OS/278 ODT!] Additionally, due to the
warped brains of those who corrupted OS/8 into OS/278, there are
needless levels of incompatibility with various OS/8 drivers written
in some cases by clever users which are not easily fixed; by restoring
the original conventions, the drivers would work; this is not a
hardware issue at all!
Any version of any software that would run on a DECmate doesn't have
the control-S/control-Q problem because the console is simulated and
buffered. However, the simulation is demented: it simulates an
incompatible subset of the original, thus OS/8 cannot run on it. OS/
278 does, except for the stuff that was left buggy. But you never
have the control-S/control-Q problem. However, other than output
explicityly directed to the variant KL8E handler, it is not supported,
thus you cannot use optional scroll start/stop or directly typing
control-S or control-Q manually. [Never a P?S/8 issue due to the lock-
step compatibility.] This is not fixable unless the DECmate hardware
is modified; it is NOT a firmware or slushware issue; all would have
to be modified, but you would have to change the motherboard first...
P?S/8 checks explicitly for the existence of the DECmate incompatible
hardware in every program, period. Thus, it always works even on the
demented hardware. As a nicety point of retro-compatibility, every
program includes once-only code to avoid needless modification should
there not be a need to implement the change. This allows the system
total compatibility on compatible hardware to run applications written
for that hardware, such as the ability to run diagnostics and
formatting programs on the machines it was meant for. [If the dynamic
check weren't there, it could cause an interrupt problem for some of
these earlier applications, and it would be all needlessly leading to
silly lockout of perfectly fine programs that for other reasons cannot
run on machines new enough to have the problems.]
To make all of that completely functional, P?S/8 has added something
in known as a logical abort condition. In OS/8, there is dependance
on the console hardware so a program can control-C out to abort. This
cannot work on a DECmate, and is why it is so pesky at aborting
programs, especially from BATCH. P?S/8 detects two aborts: Control-C
always aborts the latest program. So does control-B. However,
control-B aborts the entire BATCH if applicable, while control-C would
not abort the BATCH, just the latest program, etc. Thus, if the
logical abort condition applies, it can distinguish between the two
variants; if the hardware doesn't require the logical dynamic update,
the console hardware, being compatible, just works in the usual
manner, and the control-B aspect just becomes perhaps a superset that
might be supported; all standard P?S/8 utilities do all of the above,
but there are many programs written to exit to 07600 if control-C is
detected. Thus, P?S/8 embraces all of these applications, etc. as
long as they are running on compatible hardware, which hopefully is
the [non-DECmate] case.
The logical abort condition also allows a few tricks: A program can
"fake" an abort condition by setting the abort switches directly, not
in response to user keyboard input. Thus, if a program were to be run
from some alternate user device or even a terminal on an alternate to
an 03/04 console, such as 40/41, P?S/8 can be made to abort as if
something was typed on the standard 03/04 interface terminal, but in
fact on the alternate one, etc. [Or an experimenter could throw a
switch hooked up to some lab-8/e equipment or somesuch.]
[Note: Over the years I have pointed out that in theory, a newer OS/8
could be written to embrace pretty much the same thing. This would
lead to a system that could run just about all of the original stuff,
but only if the hardware was compatible, and also would run on
DECmates; any program or application that wanted to become DECmate
aware would run on all of them, just like P?S/8 currently does, all
other considerations aside, etc. This could clean up the mess of OS/8
"balkanization" problems.]
This eventually lead to another P?S/8 extension, generalized logical
console support. This requires the usage of the highest field of
memory locations 0000-5777, which dovetails nicely with the possible
handler extension support using 6000-7777 of the same highest field.
[Note: "sentient" enough P?S/8-aware programs can use whole or partial
fields of memory for their exclusive use, Thus, P?S/8 PAL could
realize that while the entire field isn't available, the first 3/4 of
it are, and that can be quite useful to an assembler, etc. It also
means bigger buffers for various copying-oriented utilities as well,
etc. Of course if the logical console overlay is present, this isn't
gonna be available in this specific instance.]
System calls are defined, which are essentially dynamically placed
over the console code, because the calls are designed to precisely fit
over the normal device 03/04 code one would expect in any PDP-8 system
[without interrupts; the logical console support includes console in,
console out, logical lpt out, logical lpt in, meaning it envisions a
serial printer with the need to support control-S/control-Q from the
printer, a reality with a lot of actual DEC and third-party printers
and terminals that really did get hooed to PDP-8s and/or DECmates, and
also a logical interrupt handler hook; P?S/8 FOCAL69 uses all of this
if present for example, since FOCAL69 is interrupt driven. FOCAL
first calls the logical interrupt hook, thus the relevant physical
devices don't apply, etc.]
The overlay also defines system handler optional enhancement,
including IOPS4-like error reporting. [For newbies: The PDP-9/15
ADSS system and similar report potentially recoverable errors on the
console when they happen starting with IOPS-4 and a code; for somewhat
newer people, this is what MS-DOS ripped off as "Abort, Retry,
Fail" . P?S/8 had it after the 9/15, but before PCs existed.]
Overlays have been written to support the standard console [to get the
enhanced features only], and for alternate consoles merely different
in I/O such as for KL8E or PT08 or KL8JA on device 10/11 or 40/41 etc.
or wherever else you might hook up another terminal. The VT8E is also
supported in another version.
By optionally implementing the standard device 66 LPT, another
advantage is the ability to drive faster line-printers. Many used OS/
8 and purchased truly expensive line-printers only to find that OS/8
could only print on them at a fraction of their rated speed. That's
what happens when you do not buffer the output properly. [Note: This
problem does not happen with systems such as ETOS, because the LPT is
virtualized, and the underlying hardware is properly buffered.]
However, the P?S/8 logical console LPT support is inherently buffered,
thus programs such as P?S/8 PAL can create truly voluminous output
seen to be as much as triple the speed of OS/8 on the same exact
hardware. Admittedly, if the overlay isn't enabled, P?S/8 is
typically only modestly faster than OS/8 in outputting, but this is
merely because P?S PAL is faster than PAL8 [as was demoed to DEC, as I
mentioned in a previous post in this thread]. Both would not be
buffered properly in those instances, etc. [But OS/8 has no way to
improve this; it was an embarassment within DEC when this came up; a
lot of people didn't want to talk about why the fast printer still
printed slow, etc.]
Again, OS/8 could support this sort of feature; no one bothered to
think it through.
That's about it in terms of basic requirements. Not a good place to
go into internal differences and/or file structures or device function
calls, etc.
And now back to what the express purpose of this group is [since I'm
the one that defined and implemented it; if you really question that,
go back to the back pages of the Control usenet group].
The purpose of this group is to discuss all things PDP-8 and related.
That means stuff in DEC machines usually defined as PDP-8 models or
similar and all compatibles regardless of manufacturer, home-brew
machines real, tentative or imaginary, software, peripherals real,
tentative or imaginary, restoration techniques for any and all of the
above, new or old stories about anything even remotely related. Other
than rants designed to usurp the definition, all else is allowed and
welcome. That also includes "politics" about what DEC or others did
or didn't do, as long as the topic is -centric to any of the issues.
This is not a place to discuss the PDP-11; there is another group for
that. Ditto VAXen or Alphas. If they don't have one, I would welcome
a discussion to "allow" the other DEC machines that were 18-bits, but
I don't think we are getting much traffic for -1, -4, -7, -9, -15
other than the minor applicable tidbits. It would be perfectly fine
to discuss Mark Hyde's PDP-8 simulator written to run on the PDP-15
however regardless.
Discussion of PDP-11 disk formats for use in writing conversion
programs is allowed. Thus, a discussion on the program usually known
as "RT11" is fine. For those who are unfamiliar, it allows OS/8 files
to and from RT-11 RX01/02 diskettes run from any of the machines
[other than DECmates] mentioned above configured with an RX01/RX02/
RX03 or DSD-210. [It does not support write-protect on RX01-DSD-210;
it gets confused and believes it's an RX02; avoid foil protects and/or
write-protect switches, otherwise works fine. When I released
Kermit-12, I also included it on a pair of RT-11 format RX02 diskettes
in part to make the release be able to get to any machine as much as
possible. The release includes text files of the directory printouts
from the program ala an -11 would. This allowed me to document all of
the files with three-character extensions instead of OS/8's two. This
helped the Columbia people largely unfamiliar with OS/8's 6.2
notation; they of course know MS-DOS's 8.3 notation and other "wider"
systems than OS/8, etc.
Cooperative projects between PDP-8 stuff and other machines is also
fine. Thus, the discussion can refer to PDP-10 workstation groups
running ANF-10 where something like 4 or so max TOPS10 users are
typing on PDP-8-connected Teletypes on an -8/i and can additionally
mount DECtapes actually on the -8/i but treated as if they are on the
main PDP-10 cabinets. Or the 680/i terminal concentrator on an -8/i
with just paper-tape [and the 680 hardware] where you can use the
console switch register to spy on a specific user's terminal within
the concentrator group. Some newbie TOPS-10 users were really
impressed with just how "smart" TOPS-10 was when it "corrected" their
mistakes after the fact, including scolding them for the typing errors
and performing the corrected commands for them :-) . [Little did they
realize this was a guy typing on the PDP-8 console not 30 feet away
from him.]
A perfectly good subject would be to lament how DEC outrageously
jacked up the prices of DECtape drive parts such as tape guides;
companies do that to wear you down ["buy something new"] etc.
However, due to stupidity borne originally from a typoe that just
wouldn't go away, the left guide and right guide wound up with
bizarrely different prices. When I and others reported this to the
appropriate arm of DEC that sold parts, all they would do is say "I'll
correct the price for you only, but only this once" or lied about
further correcting the database, since in fact it never was; the
prices just both went way, way up, but became ever more dissimilar.
Fortunately, today we have people with machine shop skills and tools,
so making parts is not out of the question to help restore or repair
old PDP-8-relevant equipment.
The scope of alt.sys.pdp8 is to be inclusive; about the only other
thing not tolerated here is all of this inappropriately-cross-posed
spam we all have to endure. Nothing new about it. It comes and
goes. [Not as bad as on alt.fan.charles-lasner, a group I did NOT
create!]
cjl
dpi
> ¿So, would it be possible to emulate it with a Microchip PIC.?
> I am working on it. You can see the details in pdp8r.netne.net.
> I am using a 18f452, just because that is what I can get. Once I have
> advanced in my project, I will try to get something with more I/O
> pins.
> I think the emulator will have the speed of a PDP8/S (ok for me), and
> my goal is to run FOCAL69.
> Now I am using a modifyed version of gray´s simulator, but I have
> found some problems in the code, so I am swithching to jones code.
> And I have used only about 25% of the code memory of the 18F. I have
> lot of space to do improvements.
I have written a lot of emulators. One of the first I wrote was for
an 8080 that ran on the Straight 8 I had access to at college in
1975. I was able to run the MITS 8K Basic on it successfully at about
1/5 the speed of an 8080. This was very good speed considering the
PDP8 instruction speed is marginally faster than a 2mhz 8080. I used
the second field of memory as level 1 cache and the DF-32 was the swap
space. Thus I had a 64k 8080 emulated on a PDP-8. The MITS Basic was
quite a bit better than the Polybasic because it looked like you had a
lot of memory.
I have a pretty good Straight 8 emulator. It doesn't give the same
answers on the illegal operates as the real thing does yet. The EAE
code needs a lot of work. It is written in C and runs on FreeBSD.
Running on a 3.2ghz server it is over 100 times faster than the real
machine. The Jones emulator is a little slower than mine but it is
far more complete when you look at peripheral support and general user
friendlyness. I only have keyboard/printer and papertape reader/punch
emulated currently.
I don't see any reason why you couldn't emulate an 8 using a PIC.
Using a 20mhz clock on the PIC you might even get close to full
operating speed if you code it in assembly. The PDP-8 is a very
straightforward machine. If the only real goal is to get Focal
running then there is a lot of stuff that doesn't have to work exactly
like it would on a real 8. The areas I found a little confusing were
the auto increment memory locations and the bank switching stuff.
Having a real machine to play with was very helpful. You should be
able to do the same kinds of things with the Jones emulator and you
can always grab the diagnostic papertape images and run those to help
verify your implementation.
My real 8 is currently acting a little cranky. Only the bottom 4K
works and that will run the checkerboard test for somewhere between
one and 2 minutes before it picks bits and crashes. It is always the
same bit so I swapped two of the sense amp cards and made the picked
bit move where I expected it to. Shouldn't be too hard to fix. I
just have to decide to do it.
Anyway, good luck on your project. It sounds like fun and I am
certain you will learn a lot doing it.
Doug
cjl
> On May 24, 6:57 pm, pdp8...@gmail.com wrote:
>
> > ¿So, would it be possible to emulate it with a Microchip PIC.?
> > I am working on it. You can see the details in pdp8r.netne.net.
> > I am using a 18f452, just because that is what I can get. Once I have
> > advanced in my project, I will try to get something with more I/O
> > pins.
> > I think the emulator will have the speed of a PDP8/S (ok for me), and
> > my goal is to run FOCAL69.
> > Now I am using a modifyed version of gray´s simulator, but I have
> > found some problems in the code, so I am swithching to jones code.
> > And I have used only about 25% of the code memory of the 18F. I have
> > lot of space to do improvements.
>
> I have written a lot of emulators. One of the first I wrote was for
> an 8080 that ran on the Straight 8 I had access to at college in
> 1975. I was able to run the MITS 8K Basic on it successfully at about
> 1/5 the speed of an 8080. This was very good speed considering the
> PDP8 instruction speed is marginally faster than a 2mhz 8080. I used
> the second field of memory as level 1 cache and the DF-32 was the swap
> space. Thus I had a 64k 8080 emulated on a PDP-8. The MITS Basic was
> quite a bit better than the Polybasic because it looked like you had a
> lot of memory.
POLY BASIC [perverted into EDUSystem30 and also 15/30] is designed to
completely run in 4K on a straignt-8. It uses no extensions
whatsoever, not EAE and no memory extension.
I have written elsewhere on the magic of Richard Lary's "slurp"
loader, as implemented in the original R-L monitor [also for the same
exact hardware; POLY BASIC was developed on the machine it was written
for as source files worked on completely in 4K on the R-L monitor;
modules were loaded into memory, an alternate tape was mounted, and
then the contents of memory were written out the the POLY BASIC tape,
etc. I'm not sure how many binary write operations needed to be done;
likely several because the running POLY BASIC is basically an editor
until you want to do a RUN, and then it becomes a compiler producing
binary files while reading the source file you are now no longer
editing saved to a temp area, etc. And then, if successful, a run-
time system is loaded into memory along with a slurp loader/rebooter;
the resultant binary is then slurp-loaded over the run-time system
which then [hopefully!] runs the user's BASIC program, etc.
All of this runs quite quickly; this is not a "digestive interpreter"
of anything like that. [4K BASIC and its cousin 8K BASIC and LAB-8/E
BASIC is. FOCAL is a true interpreter which is even slower.]
What you describe sounds really slow, since you are swapping from a
disk [even a DF32 still ain't memory speed], while whatever POLY BASIC
can do always fits in memory. Similar to P?S/8 in scope, the editor
and the user file must fint in 4K; the run-time system and the
resultant user program's binary must fit in 4K; nothing is virtual at
any point in time.
EDU-30 got the DEC standard treatment, but was really not
constructively different. The 15/30 variant uses the TD8E running in
4K because the machine also includes the MR8E-C TD8E ROM written by
Stan Rabinowitz and the standard -8/e extended memory controller card,
but no additional RAM. [POLY BASIC does not support any form of punch
card, which is a small feature DEC added on. The 15/30 version was
created as an accomodation to the TD8E, simply because they were
expedioent [or incapable] of adding in an additional device to support
over the standard collection prior to TD8E. [BTW, P?S/8 also has a
version that can run on the same hardware as the 15/30 version; If
you have 8K, you can run a non-ROM system, with an alternate system
handler more analogous to how OS/8 would need 12K instead of 8K and
the ROM, etc.]
Emulating something larger always costs you some compromise; disk
space ain't memory. I read somewhere that someone attempted to run OS/
8 on a 4K LINC-8 using a PDP-8 simulator that supported 8K. The other
LINCtape was used as the memory swap space for the two faked-out
fields. I believe when they finally got it functional, it was
actually able to boot up OS/8 to a prompt in less than 45 minutes!
Mark Hyde's PDP-15-based emulator runs at about 15% of a real PDP-8.
It typically gives you a 16K PDP-8 memory, and supports DECtape that
presents as TC01/08 when in fact it is the real PDP-8/15 DECtapes.
Also supports the console and the high-speed reader and punch, both at
decent speeds. I used it to punch out some binary paper-tapes someone
needed, etc.
One of the features of this program is to break out of slavish inst--x-
inst emulation and realize you are in a special routine that can run
much faster. Supported situations are:
1) OS/8 TC01/08 DECtape system handler.
2) OS/8 TC01/08 DECtape non-system handler.
3) P?S/8 TC01/08 DECtape system handler.
4) P?S/8 TC01/08 DECtape binary slurp loader.
The I/O emulator checks when certain IOTs are being attempted to
determine if the code passes a sanity check for the pragmatisms
implied. If one is recognized, it intelligently instead looks at the
calling program's arguments in the appropriate PDP-8-oriented sense.
The arguments are instead used directly by real PDP-9/15 code to carry
out the requested function. This could even include "slurping" into
memory P?S/8 binary; the technique is not unique to the PDP-8; any
DECtape hardware and several other devices can do it; just that only R-
L monitor, P?S/8 and POLY BASIC ever bothered to do it [which is why
these systems are far faster when doing binary loading. I make
reference to a "shootout" performed as a demo to DEC personnel within
the "mill" building in Maynard Mass, back in the day, etc. The
relevant point is that P?S?8 running on DECtapes loaded the same
binary content into memory twice as fast as OS/8 using its standard
method; however, the OS/8 system was running on an RK05/RK8E! The
machine was a 32K PDP-8/e with TC08 and RK8E and a fast line printer.]
Control gets returned to the calling program after the operation is
completed. Thus, the emulation resumes past the point where the I/O
was performed as a work-alike, not a slavish emulation. This is why
the program was actually reasonably useful for quite a few functions,
etc.
Much has been made of making sure that PDP-8 diagnostics are passed to
ensure the emulation is correct. Here are two stories:
On Mark's emulator, a PDP-8 memory diagnostic failed! Turns out the
PDP-15 memory actually was failing in a memory location used by the
emulator as the -8 memory space; the PDP-15 diagnostics weren't as
good as the -8 diagnostic, but eventually it was proven the -15 was
indeed faulty [and got fixed, and then all was fine].
One of the PDP-8/e random instruction generating diagnostics fails on
any IM6100-based system [VT78. PCM-12, PCM-12A, Intercept, etc.]
although most do pass. Turns out one or two of these tests are
amazingly thorough, and revealed an incompatibility:
The PDP-8/e has known "extra" quirky instructions to make it be
understood as a KK8F-CPU-based machine. They aren't supported exactly
the same way on the 6100, which in turn has a slight superset of the
-8/e in a minor way. Ignoring this, one would expect all of these
diagnostics to completely work.
However, these programs generate instructions at random to the point
that they attempt as necessary to execute instructions placed on page
0. Here is the incompatibility:
Consider the instruction TAD I 10. An auto-index instruction is so
only if all of the following are true:
1) The current page bit is off; the instruction has to reference page
0, and not the current page the instruction is located in. [Note, the
code is generally page-relocatable; for example, the instruction 1610
means TAD I relative 10 on this page, so if the code is in page 1, the
instruction means TAD I location 0210 and if on page 2, TAD I location
0410. In any case, because it is the current page, it means an
ordinary indirect. However, if the current page bit is off, the
instruction becomes 1410, thus it means the address is absolute 0010
on page 0.
2) It has to specifically reference as the pointer location 0010
through 0017. All other locations are merely indirect, and do not
expect to first auto-increment the referenced 0010-0017 before using
the updated value, etc.
Thus, for most code, it is quite clear what an auto-increment
reference is and what is not one as such.
However, what if the instruction is placed somewhere on page zero
itself? If you stick 1410 say in location 0100, it works as expected.
But if you place 1610 in location 0100, what happens?
Turns out that on a PDP-8, it doesn't matter. However, on the 6100,
it DOES matter. The decoding is done at the instruction level while
on a PDP-8 it is done at the effective address level. Thus, the 6100
has a "feature" in that it is possible to make indirect references to
0010-0017 be both auto-increment and also not auto-increment, as long
as the code doing this is placed on page zero. [Minor aside: The
LINC instruction set of all LINC machines, the LINC-8 and the PDP-12
have similar instrictions, except the scope of the auto-increment is
0001-0017, not 0010-0017. By setting a bit, you can make it work both
ways, and this can be performed from any memory location.]
To even accomplish this, you really need to randomly generate
instructions sufficiently to generate the problematic case, and
apparently not all of the diagnostics are created equal [or perhaps no
one ran all of them long enough for the problem to show up!]
At the source level, it is not straightforward to even assemble source
code to create the problem without resorting to tricks. The default
way all assemblers work couldn't create the problematic case without
resorting to direct octal codes, other than something like the
following:
*100
NOPUNCH
*300
ENPUNCH
TAD I 300
[I left out symbolic names because it only complicates the situation
without resolving the issue. Also, an alternate example can be
accomplished with the RELOC pseudo-op, but that likely requires more
of an explanation; the example given is essentially a subset of what
RELOC can accomplish when fully utilized, etc.]
Thus, it's not surprising that any real-world code tested on the 6100
just worked [other than speed], other than the specific random
instruction generating diagnostics eventually creating the problematic
case. The problem was fixed in the 6120 chip, so this problem is
irrelevant on such as DECmates and the Gizmo, etc.
Someone suggested building an Omnibus-driving CPU replacement board,
which would then support whatever peripherals were in the chassis,
unless you explicitly also wanted to simulate them on host-system real
peripherals. With the hopefully soon availability of USB 3.0 as a new
hardware standard, this wouldn't have to be much of a project to
implement that replaces the entire CPU card set, including optional
EAE. Playing the PDP-8/a processor trick and restricting the entire
buss to 20 slots or less, the terminator could also be removed. Of
course you could also put some imbedded machine on the board, but by
making it a USB peripheral would make the project be quite flexible.
I/O timing could be accurately maintained, while raising effective CPU
speed dramatically. Also, CPU-family quirks could be emulated as
well, to test model-dependent code, etc. The FPP-12 or FPP-8/a [e]
could also be emulated easily on the host system.
cjl
dpi
> On Jun 5, 6:15 pm, dpi <doug.ingra...@gmail.com> wrote:
> > I have written a lot of emulators. One of the first I wrote was for
> > an 8080 that ran on the Straight 8 I had access to at college in
> > 1975. I was able to run the MITS 8K Basic on it successfully at about
> > 1/5 the speed of an 8080. This was very good speed considering the
> > PDP8 instruction speed is marginally faster than a 2mhz 8080. I used
> > the second field of memory as level 1 cache and the DF-32 was the swap
> > space. Thus I had a 64k 8080 emulated on a PDP-8. The MITS Basic was
> > quite a bit better than the Polybasic because it looked like you had a
> > lot of memory.
<snip>
> What you describe sounds really slow, since you are swapping from a
> disk [even a DF32 still ain't memory speed], while whatever POLY BASIC
> can do always fits in memory. Similar to P?S/8 in scope, the editor
> and the user file must fint in 4K; the run-time system and the
> resultant user program's binary must fit in 4K; nothing is virtual at
> any point in time.
The fact that my emulator wasn't incredibly slow surprised me greatly
at the time. The approach I used to make the emulator faster was
pretty simple. I used the second field of memory as a cache. The
8080's 16 bit registers (PC, SP, BC, DE, HL) were all usable as memory
pointers. Each one of these when used as to do a memory reference
could load a chunk of memory from the DF-32. I kept 8 blocks of 512
words in memory (field 1) using a LRU algorithm to cause a write out
if the page was marked as dirty and then load in the required new
page. This worked really well for the PC and the SP since they mostly
hover around the same memory addresses and thus you would get a very
high cache hit ratio on these. It was easy to write code that would
execute slowly but little programs like the MITS 8k basic tended to
run really well because they were coded so tightly. I considered
going to 16 pages of 256 byte blocks which might have increased the
cache hit ratio a little bit but there was some reason this didn't
work out which I can't remember now. The DF-32 was not all that fast
but it beat the pants off of dectape.
I wasn't implying that polybasic was slow. Far from it! It is still
pretty amazing when you play with it how useful it is (was?). I found
it to be a lot more fun to play with than Focal or Fortran. I did
most of my 8 coding in assembly.
> Emulating something larger always costs you some compromise; disk
> space ain't memory. I read somewhere that someone attempted to run OS/
> 8 on a 4K LINC-8 using a PDP-8 simulator that supported 8K. The other
> LINCtape was used as the memory swap space for the two faked-out
> fields. I believe when they finally got it functional, it was
> actually able to boot up OS/8 to a prompt in less than 45 minutes!
This is kind of what I was expecting to see and was surprised when it
was actually usable. Or maybe the fact that it wasn't that slow made
it seem usable. I suppose you could ask what it was used for and the
answer was nothing but the satisfaction of doing it.
I will remember this approach for future projects. It could be a
major improvement in a lot of areas.
> Much has been made of making sure that PDP-8 diagnostics are passed to
> ensure the emulation is correct. Here are two stories:
>
> On Mark's emulator, a PDP-8 memory diagnostic failed! Turns out the
> PDP-15 memory actually was failing in a memory location used by the
> emulator as the -8 memory space; the PDP-15 diagnostics weren't as
> good as the -8 diagnostic, but eventually it was proven the -15 was
> indeed faulty [and got fixed, and then all was fine].
I imagine that there was a lot of head scratching over this "bug"!
> One of the PDP-8/e random instruction generating diagnostics fails on
> any IM6100-based system [VT78. PCM-12, PCM-12A, Intercept, etc.]
> although most do pass. Turns out one or two of these tests are
> amazingly thorough, and revealed an incompatibility:
I have the paper tapes and the DEC listings for most of the Straight 8
Diagnostics and when you read through it you come to realize that a
LOT of effort went into those diagnostics.
Doug Ingraham
cjl
All too true! If that LINC-8 had a DF32 to swap off of instead of the
other LINCtape [Note: LINC-8 LINCtape is about a 3/4 speed version of
DECtape in terms of performance. This is part of why it handles the
tapes so gently without guide tweaks, etc. but it is slower.] that
emulator would have probably only taken about 3 minutes to boot, etc.
However, LINCtapes hold a whole lot more than a DF32.
In any case, you had more memory to implement a cache, always a really
good feature where relevant. It is often true that there are large
overall shifts, but locally a lot of time spent in a relatively small
memory space. Thus, caching can often provide profound improvement.
[I along with others once wrote a PDP-8 multi-user application system
with a custom directory format; without the caching support it would
have run literally hundreds if not thousands of times as slow; the
application created thousands of petty files in a balanced B-tree
directory format that dynamically grew, etc. At any given point, most
users were working on similar file names, thus nearly all directory
blocks being cached, were hardly ever read back in from the disk,
saving a lot of probes. Once the region of interest was dynamically
adjusted, little directory block I/O was performed, likely just the
leaf record to update the file info/time stamp, etc. allowing the
system to concentrate instead on getting the file innards themselves,
etc.]
>
> I wasn't implying that polybasic was slow. Far from it! It is still
> pretty amazing when you play with it how useful it is (was?). I found
> it to be a lot more fun to play with than Focal or Fortran. I did
> most of my 8 coding in assembly.
As did most of us. But sometimes you have to accomodate people who
aren't gonna do it. For most of what I encountered, I found FOCAL
more useful largely because it was so modifiable for custom purposes.
I wrote literally dozens of FOCAL patches to implement internal
functions to do all sorts of stuff scientist/amateur programmers
needed. Thus, they merely called assembly stuff that did the
esoterica, while they otherwise wrote high-level code to crank out the
math they understood, etc.
POLY BASIC is a standalone BASIC-only O/S, so not useful for that sort
of usage; the paper-tape digestive interpreter BASIC's cannot run from
O/S environments because they write over every word in memory; they
are trule standalone and wipeout whatever is in 07600-0777, so not
even compatible with paper-tape other than to get it initially
loaded. Thus, yet another non-solution for the kinds of problems I
had to deal with, etc.
>
> > Emulating something larger always costs you some compromise; disk
> > space ain't memory. I read somewhere that someone attempted to run OS/
> > 8 on a 4K LINC-8 using a PDP-8 simulator that supported 8K. The other
> > LINCtape was used as the memory swap space for the two faked-out
> > fields. I believe when they finally got it functional, it was
> > actually able to boot up OS/8 to a prompt in less than 45 minutes!
>
> This is kind of what I was expecting to see and was surprised when it
> was actually usable. Or maybe the fact that it wasn't that slow made
> it seem usable. I suppose you could ask what it was used for and the
> answer was nothing but the satisfaction of doing it.
The Mt Everest phenomena accounts for a lot of stuff :-) .
At Brooklyn Poly, we could have done nothing, after all, it was there
and it didn't do much. Had that attitude prevailed, much of what we
are all talking about wouldn't have happened. The work of the people
who congregated around the original straight-8 we had caused a
significent percentage of what eventually drove the sales of the PDP-8
product line. What computers would sell without software to maket
them useful? [Remember, PDP-8s were sold originally not only without
disk-oriented software, but without storage devices necessarily!]
[Historic note: The EE department bought the original machine spec'd
only based on their misunderstanding about what minimally was
necessary to do projected EE projects, which were quite elementary.
Software and its development was something they were clueless about.
Fortunately, a DEC salesman recommended this new-fangled thing called
DECtape, albeit with only one drive.
Please note that separately, someone once proved that you can develop
code faster on this configuration without a DECtape if you have a high-
speed reader/punch, if you use only the DECtape version of the Disk
Monitor System. R-L and later P?S/8 completely reversed this.
In any case, nothing added to this machine was high-speed. Just a
TTY: and the DECtape, 4K, A-D, D-A, and EAE.
Thus, without our early pioneer "mountain climbers" this would have
meant that pretty much all we eventually took for granted in the 12-
bit world wouldn't have happened. The PDP-8 would have just died as
yet another almost useless machine [like the PDP-4] and likely DEC
would have done nothing until the PDP-11 came along [or the Nova if
you know the history]. But they wouldn't have had the stature of a
company capable of making a viable small machine, since up until then,
the only division to otherwise reckon with was LCG, i.e., the PDP-10.
Any predictable emulation loop that can be easily checked for should
be done as a work-alike instead of step-by-slavish-step. The trick is
to identify that which can be tweaked this way. In his case, the
situation was totally contrived and thus easily implemented.
>
> > Much has been made of making sure that PDP-8 diagnostics are passed to
> > ensure the emulation is correct. Here are two stories:
>
> > On Mark's emulator, a PDP-8 memory diagnostic failed! Turns out the
> > PDP-15 memory actually was failing in a memory location used by the
> > emulator as the -8 memory space; the PDP-15 diagnostics weren't as
> > good as the -8 diagnostic, but eventually it was proven the -15 was
> > indeed faulty [and got fixed, and then all was fine].
>
> I imagine that there was a lot of head scratching over this "bug"!
Yes, but in the end, it did prove the machine was broken, and field
circus had to make good on the memory repair.
>
> > One of the PDP-8/e random instruction generating diagnostics fails on
> > any IM6100-based system [VT78. PCM-12, PCM-12A, Intercept, etc.]
> > although most do pass. Turns out one or two of these tests are
> > amazingly thorough, and revealed an incompatibility:
>
> I have the paper tapes and the DEC listings for most of the Straight 8
> Diagnostics and when you read through it you come to realize that a
> LOT of effort went into those diagnostics.
Yes, and what is not so clear:
Unlike the newer stuff that got mostly written in PAL10, most of those
earlier-still diagnostics were written originally in PAL II, not even
PAL III.
PAL II was pretty pathetic. It didn't even support or understand the
notion of exactly where to reckon any expression used as an address
actually was. Thus, if you left out any "help" in your source code,
the operand was always presumed to be on the current page! Thus, in
order to make the code even work, all page zero references required
the use of the Z pseudo-op. Thus, ridiculous statements could look
like:
TAD I Z 10
instead of
TAD I 10
This has nothing to do with any symbolics, just a pathetic quirk of
this primitive ancient piece of bad code.
Eventually, PAL III was released which made writing code merely
annoying because of paper-tape, not the inherent language. Richard
Lary adapted PAL III for use on the original R-L monitor, so you could
type up source files and assemble them on the O/S. No paper-tape
considerations whatsoever.
PAL III itself, although originally written in PAL II, had its source
code modernized by PAL III team lackey Ed Yourdan, who often billed
himself as larger than life in this respect. Essentially, he removed
all of the Z pseudo-op usage because PAL III doesn't use/need it.
Thus, the eventual PAL III source code could assemble itself, etc.
In PAL8, the Z pseudo-op is literally ignored. P?S/8 doesn't use PAL
III, and has its own assembler, P?S PAL. In the P?S?8 assembler, the
Z is actually obeyed for more compatibility with PAL II source code.
[After all, if the programmer insisted on using the Z, perhaps he had
something else in mind beyond "helping" the assembler, such as doing
something odd that defied the normal "intelligence" that was later
standard in PAL III and all newer assemblers.]
Thus, in PAL II and P?S/8 PAL, the current page bit is forced off (bit-
cleared against 0200), although in P?S PAL, most normal assembly
shouldn't have the bit on. In PAL III it's an error to have the Z
present, and in PAL8 it is merely ignored.
Oddly enough, PAL II without resorting to adding in the Z, could
assemble code to exploit the oddness of the IM6100 chip, while all
other known assemblers couldn't create the code that is incompatible
without resorting to the trickery I mentioned earlier, etc. Thus,
while all other assemblers would generate 1410 for TAD I 10, PAL II
would generate 1610 for the same source code; generally wrong but what
you want to assemble to reveal the hardware bug on the 6100.
However, I doubt if PAL II was ever run on any machine as new as an
IM6100 :-) .
>
> Doug Ingraham- Hide quoted text -
>
> - Show quoted text -
cjl