PDP-8/As, 8/Es, Core, MOS and TD8Es ...
Bob Armstrong
According to the PDP-8/A manual, the KK8-A and the MM8-A core
memories both have a cycle time of 1.5us. The manual also says that
the MS8-A (1, 2 and 4K) MOS memories have a cycle time of 2.4 or 2.8us
- fetches are faster than all other accesses (dunno why!). The MOS
memories use the NTS STALL OMNIBUS signal to force "wait states" and
slow the CPU down.
The KK8-E (PDP-8/E CPU) however has a cycle time of 1.2uS. Does
this mean that if you put a KK8-E in a 8/A chassis with the MM8-A, you
get a 1.2us cycle (i.e. the MM8-A is actually faster than the 1.5us
specification)? DEC sold 8/A systems configured this way (e.g. the 8/
A 600 and 8/A 620), so I'd assume there was some speed advantage to it
but I haven't found anything that says for sure. And can I assume
that a KK8-E with MOS memories would be just as slow as the 8/A ?
And I don't have any information on the MS8-C (16, 32 and 128K) MOS
boards. Were they the same speed as the MS8-A or were they (fingers
crossed here) faster?
Why would anybody care? Well, the TD8-E ("Simple DECtape
Interface") uses software to do a lot of the stuff that the TC08 did
in hardware - with the TD8-E the software assembles the 12 bit words,
stores them in memory, searches for the right block numbers, etc.
This is a great cost and hardware saver, but it's a lot more software
intensive and I've heard that the 8/A with MOS memory is not fast
enough to keep up. That's makes sense, since that configuration would
only be about 1/2 the speed of the 8/E with core memory.
But does an 8/A with core memory (only slightly slower than the 8/E)
work with the TD8-E?
As you might have guessed, I have an 8/A with MOS memory and I want
to add a TD8-E/TU56, so this is more than a purely academic question.
And of course I don't have a MM8-A core board.
And how come the MOS memories were soooo slow? 2.8us is 2800ns -
that's _really_ slow, even by 1975 standards. Was that just because
of the refresh?
Thanks,
Bob Armstrong
David Gesswein
Bob Armstrong <b...@jfcl.com> wrote:
>
> The KK8-E (PDP-8/E CPU) however has a cycle time of 1.2uS. Does
>this mean that if you put a KK8-E in a 8/A chassis with the MM8-A, you
>get a 1.2us cycle (i.e. the MM8-A is actually faster than the 1.5us
>specification)?
>
http://www.faqs.org/faqs/dec-faq/pdp8-models/
It looks like the 8k is too slow but the 16k will work with an 8/E CPU.
> And I don't have any information on the MS8-C (16, 32 and 128K) MOS
>boards. Were they the same speed as the MS8-A or were they (fingers
>crossed here) faster?
>
A little information is in here but not enough
http://www.pdp8online.com/pdp8cgi/query_docs/tifftopdf.pl/pdp8prints/ms8-c.pdf
May be able to see if this person got that combination working.
http://www.classiccmp.org/pipermail/cctalk/1999-November/136821.html
Bob Armstrong
> A little information is in here but not enoughhttp://www.pdp8online.com/pdp8cgi/query_docs/tifftopdf.pl/pdp8prints/...
Thanks - this link was really helpful on the MS8-C -
http://www.pdp8online.com/pdp8cgi/query_docs/tifftopdf.pl/pdp8prints/ms8-c.pdf
If I read it right, it seems to say that the MS8C has a cycle time
of 1.2/1.4us (i.e. just as fast as the KK8-E) and that it does
transparent refresh (i.e. the refresh doesn't slow down the CPU at
all).
And if I read it right, it seems like the only time the MS8C uses
NTS STALL is when the processor first starts up (i.e. goes from the
HALT state to RUN), and that's just to synchronize the transparent
refresh cycles with the CPU.
If all that's correct, then it ought to be possible to use the MS8C
with the TD8E. Can anybody confirm this?
THanks again,
Bob
Johnny Billquist
Bob, what I can tell, now that I've atleast started reading my old manuals, is
that the TD8-E should work with all PDP-8/A models.
And the TD8-E don't do bit fiddling by the CPU. The CPU reads/writes whole
12-bit words, and the controller do the fiddling for you.
But it's not a DMA device. It's not even generating interrupts. You always have
to poll it. That's what sucks about it, and what made device drivers in any
sensible OS a bit tricky. Systems eventually managed to support them fairly ok
by doing a few tricks. KNowing the current block #, and the block you are
searching for, you can estimate the time before you've searched the right
distance, and can have a clock interrupt you when it's time to start polling.
And then (or course), you have to more or less hang the system while the block
is being read in by a polled loop.
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
David Powell
>Bob Armstrong skrev:
>> On Apr 29, 4:45 am, d...@pdp8.net (David Gesswein) wrote:
>>
>>> A little information is in here but not enoughhttp://www.pdp8online.com/pdp8cgi/query_docs/tifftopdf.pl/pdp8prints/...
>>
>> Thanks - this link was really helpful on the MS8-C -
>>
>> http://www.pdp8online.com/pdp8cgi/query_docs/tifftopdf.pl/pdp8prints/ms8-c.pdf
>>
>> If I read it right, it seems to say that the MS8C has a cycle time
>> of 1.2/1.4us (i.e. just as fast as the KK8-E) and that it does
>> transparent refresh (i.e. the refresh doesn't slow down the CPU at
>> all).
>>
>> And if I read it right, it seems like the only time the MS8C uses
>> NTS STALL is when the processor first starts up (i.e. goes from the
>> HALT state to RUN), and that's just to synchronize the transparent
>> refresh cycles with the CPU.
>>
>> If all that's correct, then it ought to be possible to use the MS8C
>> with the TD8E. Can anybody confirm this?
>>
>> THanks again,
>> Bob
>
>Bob, what I can tell, now that I've atleast started reading my old manuals, is
>that the TD8-E should work with all PDP-8/A models.
Yes, according to the 8/A handbook, the TD8E was designed for the 8/E,
8/F, 8/M and 8/A series of minicomputers, but I wonder how much was
known about the future 8/A when TD8E was designed. I only ever used
core on 8/As, so I'm not sure about the SRAM stuff. - certainly it
would run a TD8/E with DRAM memory. About 40 memory references to
read a TD8E word and build the checksum, ~130us between words, so the
slow SRAM memory just about makes it. IIRC +_ 25% tolerance on the
time, so it's a bit iffy. Unlikely to work with MR8FB memory.
My view is that MRS8 memory was intended for (P)ROM / RAM
bottom-of-the-range embedded systems. KIT8/A with a 1K "stack" cost
about 350 pounds, 1975ish. Pretty much the same market as for the
original LSI-11 with onboard memory.
Out of curiosity, does anyone know what memory the 8A500 used for WPS
1975ish uses?
>And the TD8-E don't do bit fiddling by the CPU. The CPU reads/writes whole
>12-bit words, and the controller do the fiddling for you.
>
>But it's not a DMA device. It's not even generating interrupts. You always have
>to poll it. That's what sucks about it, and what made device drivers in any
>sensible OS a bit tricky.
Dunno, it was designed as a cheap'n'cheerful alternative to TC08 for
OS/8, an O/S that can achieve its purpose without the use of
interrupts and is sensible enough not to complicate things by using
interrupt i/o when it isn't necessary. If you must run -8 DECtapes
under interrupt control, buy a TC08, that one doesn't suck, but it can
bite.
> Systems eventually managed to support them fairly ok
>by doing a few tricks. KNowing the current block #, and the block you are
>searching for, you can estimate the time before you've searched the right
>distance, and can have a clock interrupt you when it's time to start polling.
>And then (or course), you have to more or less hang the system while the block
>is being read in by a polled loop.
>
Good luck with that, can't see if flying very well. Which systems
used such tricks? I know that OS8 Fortran IV does some tricks to
allow ION operation of the RTS when using TC08, RF08 or RK8 but they
don't work for TD8E.
Regards,
David P.
Johnny Billquist
> In article <fvd1hf$mdv$1...@Tempo.Update.UU.SE>,
> Johnny Billquist <b...@update.uu.se> in alt.sys.pdp8 wrote:
>
>> And the TD8-E don't do bit fiddling by the CPU. The CPU reads/writes whole
>> 12-bit words, and the controller do the fiddling for you.
>>
>> But it's not a DMA device. It's not even generating interrupts. You always have
>> to poll it. That's what sucks about it, and what made device drivers in any
>> sensible OS a bit tricky.
>
> Dunno, it was designed as a cheap'n'cheerful alternative to TC08 for
> OS/8, an O/S that can achieve its purpose without the use of
> interrupts and is sensible enough not to complicate things by using
> interrupt i/o when it isn't necessary. If you must run -8 DECtapes
> under interrupt control, buy a TC08, that one doesn't suck, but it can
> bite.
My "problem" with the TC08 is that it's a posibus/negibus device. So no nice and
tidy card in the Omnibus, but instead a bus adapter, a whole bunch of cables,
and a whole cabinet for the controller.
>> Systems eventually managed to support them fairly ok
>> by doing a few tricks. KNowing the current block #, and the block you are
>> searching for, you can estimate the time before you've searched the right
>> distance, and can have a clock interrupt you when it's time to start polling.
>> And then (or course), you have to more or less hang the system while the block
>> is being read in by a polled loop.
>>
>
> Good luck with that, can't see if flying very well. Which systems
> used such tricks? I know that OS8 Fortran IV does some tricks to
> allow ION operation of the RTS when using TC08, RF08 or RK8 but they
> don't work for TD8E.
MULTOS-8 do that. I think others also do, but I should check it out. I seem to
remember that RTS-8 can, but that's more of a hazy memory.
The Fortran IV runtime system always runs with interrupts on... It only uses the
OS/8 device drivers for mass storage devices, and that usually works just fine,
since the OS/8 drviers don't use interrupts, nor turn interrupts on on the
device that is operating.
Vincent Slyngstad
> My "problem" with the TC08 is that it's a posibus/negibus device. So no
> nice and tidy card in the Omnibus, but instead a bus adapter, a whole
> bunch of cables, and a whole cabinet for the controller.
Seems like the controller would mount behind the TU56 drive (isn't that how
it was done?), and not take up much (if any) additional rack space.
There are a few extra cables, though :-).
Vince
Johnny Billquist
I should probably look again in our 8/i, but I think my memory is still okay. :-)
The controller takes the lower half of a 19" cabinet. You usually have drives in
the upper half. There is a whole bunch of blinkelights, and also a few switches
that you might want to access occasionally, so you do want to have it towards
the front.
If I remember correctly, you can put three TU55 in the same cabinet as the
controller. Our fourth TU55 sits in the same cabinet as the 8/i.
David Powell
>David Powell skrev:
>> In article <fvd1hf$mdv$1...@Tempo.Update.UU.SE>,
>> Johnny Billquist <b...@update.uu.se> in alt.sys.pdp8 wrote:
>>
>>> And the TD8-E don't do bit fiddling by the CPU. The CPU reads/writes whole
>>> 12-bit words, and the controller do the fiddling for you.
>>>
>>> But it's not a DMA device. It's not even generating interrupts. You always have
>>> to poll it. That's what sucks about it, and what made device drivers in any
>>> sensible OS a bit tricky.
>>
>> Dunno, it was designed as a cheap'n'cheerful alternative to TC08 for
>> OS/8, an O/S that can achieve its purpose without the use of
>> interrupts and is sensible enough not to complicate things by using
>> interrupt i/o when it isn't necessary. If you must run -8 DECtapes
>> under interrupt control, buy a TC08, that one doesn't suck, but it can
>> bite.
>
>My "problem" with the TC08 is that it's a posibus/negibus device. So no nice and
>tidy card in the Omnibus, but instead a bus adapter, a whole bunch of cables,
>and a whole cabinet for the controller.
>
Dunno, but comparing like for like, ie for an omnibus machine, I've
always managed to get a TC08 in the came cab as the cpu. My present
-8m has only TC08 and it all fits in a 4 foot high cab.
>>> Systems eventually managed to support them fairly ok
>>> by doing a few tricks. KNowing the current block #, and the block you are
>>> searching for, you can estimate the time before you've searched the right
>>> distance, and can have a clock interrupt you when it's time to start polling.
>>> And then (or course), you have to more or less hang the system while the block
>>> is being read in by a polled loop.
>>>
>>
>> Good luck with that, can't see if flying very well. Which systems
>> used such tricks? I know that OS8 Fortran IV does some tricks to
>> allow ION operation of the RTS when using TC08, RF08 or RK8 but they
>> don't work for TD8E.
>
>MULTOS-8 do that. I think others also do, but I should check it out. I seem to
>remember that RTS-8 can, but that's more of a hazy memory.
>
Ok, lets have the TD8E doing an I/O transfer, a 16 channel muxed A/D
receiving all 16 channels, one every 25us or so, at a once a second
repetition rate and throw in some 9600bd async stuff for good measure.
Not much of an interrupt load for an 8-E doing real-time stuff.
>The Fortran IV runtime system always runs with interrupts on... It only uses the
>OS/8 device drivers for mass storage devices, and that usually works just fine,
>since the OS/8 drviers don't use interrupts, nor turn interrupts on on the
>device that is operating.
>
Agreed, no problem at all, except for TD8E. The other devices don't
care if the CPU is processing interrupts during a data transfer, they
can wait, at worst, a few extra rotations for an RX01. TD8E cannot
do that, once a transfer has started it must have CPUtime to deal with
one word every 130us, In a special case, (say) just ISZ a tick
counter with minimal context save for the RTC maybe, but in general it
just won't fly.
Regards,
David P.
Johnny Billquist
> In article <g0gmuh$bjm$1...@Tempo.Update.UU.SE>,
> Johnny Billquist <b...@update.uu.se> in alt.sys.pdp8 wrote:
>
>> David Powell skrev:
>>> In article <fvd1hf$mdv$1...@Tempo.Update.UU.SE>,
>>> Johnny Billquist <b...@update.uu.se> in alt.sys.pdp8 wrote:
>>>
>>>> And the TD8-E don't do bit fiddling by the CPU. The CPU reads/writes whole
>>>> 12-bit words, and the controller do the fiddling for you.
>>>>
>>>> But it's not a DMA device. It's not even generating interrupts. You always have
>>>> to poll it. That's what sucks about it, and what made device drivers in any
>>>> sensible OS a bit tricky.
>>> Dunno, it was designed as a cheap'n'cheerful alternative to TC08 for
>>> OS/8, an O/S that can achieve its purpose without the use of
>>> interrupts and is sensible enough not to complicate things by using
>>> interrupt i/o when it isn't necessary. If you must run -8 DECtapes
>>> under interrupt control, buy a TC08, that one doesn't suck, but it can
>>> bite.
>> My "problem" with the TC08 is that it's a posibus/negibus device. So no nice and
>> tidy card in the Omnibus, but instead a bus adapter, a whole bunch of cables,
>> and a whole cabinet for the controller.
>>
>
> Dunno, but comparing like for like, ie for an omnibus machine, I've
> always managed to get a TC08 in the came cab as the cpu. My present
> -8m has only TC08 and it all fits in a 4 foot high cab.
That sounds like a really tight squeeze!
I seem to remember that the TC08 took like 3 panels worth of real estate.
But since the 8/m is rather shallow, you could place the TC08 on the back end,
and the 8/m at the front, along with some drives, perhaps?
Fun that people do these kind of things (still).
>>>> Systems eventually managed to support them fairly ok
>>>> by doing a few tricks. KNowing the current block #, and the block you are
>>>> searching for, you can estimate the time before you've searched the right
>>>> distance, and can have a clock interrupt you when it's time to start polling.
>>>> And then (or course), you have to more or less hang the system while the block
>>>> is being read in by a polled loop.
>>>>
>>> Good luck with that, can't see if flying very well. Which systems
>>> used such tricks? I know that OS8 Fortran IV does some tricks to
>>> allow ION operation of the RTS when using TC08, RF08 or RK8 but they
>>> don't work for TD8E.
>> MULTOS-8 do that. I think others also do, but I should check it out. I seem to
>> remember that RTS-8 can, but that's more of a hazy memory.
>>
>
> Ok, lets have the TD8E doing an I/O transfer, a 16 channel muxed A/D
> receiving all 16 channels, one every 25us or so, at a once a second
> repetition rate and throw in some 9600bd async stuff for good measure.
> Not much of an interrupt load for an 8-E doing real-time stuff.
True, and you know that it won't fly with the TD8E. :-)
>> The Fortran IV runtime system always runs with interrupts on... It only uses the
>> OS/8 device drivers for mass storage devices, and that usually works just fine,
>> since the OS/8 drviers don't use interrupts, nor turn interrupts on on the
>> device that is operating.
>>
>
> Agreed, no problem at all, except for TD8E. The other devices don't
> care if the CPU is processing interrupts during a data transfer, they
> can wait, at worst, a few extra rotations for an RX01. TD8E cannot
> do that, once a transfer has started it must have CPUtime to deal with
> one word every 130us, In a special case, (say) just ISZ a tick
> counter with minimal context save for the RTC maybe, but in general it
> just won't fly.
I won't argue with you. Like I said. The TD8E sucks bigtime. I'm impressed that
some OSes even managed to get support for the TD8E in there at all, but it is at
the price of getting some unresponsiveness when I/O happens to that device.
They do need to run with interrupts off during the time the actual data transfer
happens, even if they do dead time reconing for the seeks.
Mike Ross
wrote:
>Johnny Billquist wrote ...
>> My "problem" with the TC08 is that it's a posibus/negibus device. So no
>> nice and tidy card in the Omnibus, but instead a bus adapter, a whole
>> bunch of cables, and a whole cabinet for the controller.
>
>Seems like the controller would mount behind the TU56 drive (isn't that how
>it was done?), and not take up much (if any) additional rack space.
There's a little more to a TC08 than that...
http://www.corestore.org/tc08.htm
Mike
--
http://www.corestore.org
'As I walk along these shores
I am the history within'
Vincent Slyngstad
> On Thu, 15 May 2008 19:00:10 GMT, "Vincent Slyngstad" wrote:
>>Seems like the controller would mount behind the TU56 drive (isn't that
>>how
>>it was done?), and not take up much (if any) additional rack space.
>
> There's a little more to a TC08 than that...
>
> http://www.corestore.org/tc08.htm
Hmm. I hadn't thought about the power supplies, and in your pictures I
see an extra power supply and large power controller that I wouldn't have
expected, but there's still a lot of free space in that rack :-). Certainly
enough to get Johnny's 8/e in there, and maybe a PC04 or something else,
too.
Vince
David Powell
There's only one quad-high wirewrap backplane, fitted on a swing-out
gate behind the TU56, the electronics psu is fixed behind the power
control box, the lamps panel and its psu goes anywhere, only really
useful if debugging or dealing with hardware problems. Looks like
there's space enough for an RK05 as well.
>Fun that people do these kind of things (still).
>
It was built up in 1979 as a portable computer. Travels on its back
in a light van, just fits in a Vauxhall Astra. One man loading then,
but I'd need help to move it now. It was my Mk 2 version of a
portable -8. The Mk 1 was in a heavy industrial enclosed rack with 4
removable eye-bolts on the side panels. Carried by two or four guys
on two scaffold poles passing thro' the eye-bolts, sedan chair
fashion.
>>>>> Systems eventually managed to support them fairly ok
>>>>> by doing a few tricks. KNowing the current block #, and the block you are
>>>>> searching for, you can estimate the time before you've searched the right
>>>>> distance, and can have a clock interrupt you when it's time to start polling.
>>>>> And then (or course), you have to more or less hang the system while the block
>>>>> is being read in by a polled loop.
>>>>>
>>>> Good luck with that, can't see if flying very well. Which systems
>>>> used such tricks? I know that OS8 Fortran IV does some tricks to
>>>> allow ION operation of the RTS when using TC08, RF08 or RK8 but they
>>>> don't work for TD8E.
>>> MULTOS-8 do that. I think others also do, but I should check it out. I seem to
>>> remember that RTS-8 can, but that's more of a hazy memory.
>>>
>>
>> Ok, lets have the TD8E doing an I/O transfer, a 16 channel muxed A/D
>> receiving all 16 channels, one every 25us or so, at a once a second
>> repetition rate and throw in some 9600bd async stuff for good measure.
>> Not much of an interrupt load for an 8-E doing real-time stuff.
>
>True, and you know that it won't fly with the TD8E. :-)
>
Can't think of any reasonable interupt driven task that will fly with
a TD8E. :-)
>>> The Fortran IV runtime system always runs with interrupts on... It only uses the
>>> OS/8 device drivers for mass storage devices, and that usually works just fine,
>>> since the OS/8 drviers don't use interrupts, nor turn interrupts on on the
>>> device that is operating.
>>>
>>
>> Agreed, no problem at all, except for TD8E. The other devices don't
>> care if the CPU is processing interrupts during a data transfer, they
>> can wait, at worst, a few extra rotations for an RX01. TD8E cannot
>> do that, once a transfer has started it must have CPUtime to deal with
>> one word every 130us, In a special case, (say) just ISZ a tick
>> counter with minimal context save for the RTC maybe, but in general it
>> just won't fly.
>
>I won't argue with you. Like I said. The TD8E sucks bigtime. I'm impressed that
>some OSes even managed to get support for the TD8E in there at all,
It did all that it was intended to do as an part of an entry level
OS/8 system. Agreed, no point in continuing.
>but it is at
>the price of getting some unresponsiveness when I/O happens to that device.
>They do need to run with interrupts off during the time the actual data transfer
>happens, even if they do dead time reconing for the seeks.
>
Regards,
David P.