>
>Subject: Do old FPGA's decay?
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Thu, 01 Dec 2005 02:07:31 -0800
> To: cctalk at classiccmp.org
>
>But do old FPGA's just quietly go belly-up? Or is there something about
>the XC2064-50 that I'm in the dark about? Are there any easy tests that I
>can apply to confirm my suspicions?
>
Not that I know of and I use them. Years ago Tim gave me a bunch of 2064s
and 3030s to learn FPGAs and I've used a bunch of them. All of mine load
>from an eprom and I've had the eeprom that loads it fail. Like any device
it can fail though.
At power up it should have activity on the programming IO.
Allison
> So, given that assumption for now, anyone know of a likely fault
> in a typical SMPSU that might cause such a catastrophic chip
> failure but no other obvious damage?
The switching transistor has probably gone s/c which ends up
connecting the rectified mains to the switch output on the IC.
They tend not to last long when that happens.
Lee.
..
___________________________________________________________
WIN ONE OF THREE YAHOO! VESPAS - Enter now! - http://uk.cars.yahoo.com/features/competitions/vespa.html
On Wed, 30 Nov 2005 22:39:07 -0500 Allison <ajp166 at bellatlantic.net> wrote:
>>>Subject: Re: Timing of PDP-11 Instructions
>>> From: "Jerome H. Fine" <jhfinexgs2 at compsys.to>
>>> Date: Wed, 30 Nov 2005 21:57:37 -0500
>>> To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
>>>
>
>>>I am still not able to figure out why the FORTRAN 77
>>>subroutine has different timing when the destination
>>>address is moved from PAR0 to PAR1 under RT-11 under
>>>both E11 and a real PDP-11/73. Cache has been suggested,
>>>so I will attempt the calculation with a PDP-11/23
>>>which does not have any cache.
>>>
>>>Sincerely yours,
>>>
>>>Jerome Fine
>
>
>Cache is half the answer. The other half is when you hit the bus
>on a cache miss two things have to happen. You have to do bus
>transactions which are very slow compared to cache and you have to
>refill the cache. IF there is any MMU action required
>(pagein/pageou) you add that overhead as well.
Nonsense!
No PDP-11 operating system have demand paging and page faults. It could
be done, but noone is doing it.
So you just have the memory access instead of a cache hit. But memory
access is just so much slower. And the bus transaction is a part of that
memory access.
Oh, and the cache is working on *physical* address, not virtual. (You
would get serious problems if you used the virtual address for the
cache.) So, before you can even figure out if the data is in the cache
or not, the MMU must do the address translation.
>Remember the PDP11 is 16 bits. Any addressing outside ~28kwords
>is going to involve a MMU operation. That a lot of register
>access and it's costly(in time), more so if you need to move
>the Dmap in an I&D machine (11/73). The reason for that is those
>actions lie inside the core OS and require system calls to process.
>E11 is just being faithful to the core PDP11 so I'd expect similar
>if not exact same behavour. You didn't say RTll SJ or FB.
This also seems like a silly statement. From a program point of view,
you cannot access anything outside 32Kword. Never. Like you say: the
PDP-11 is a 16-bit architecture.
The MMU is always involved in mapping your 16-bit address into the
22-bit address space The memory is sitting on a 22-bit address space, so
you *must* generate a 22-bit physical address. With the MMU disabled,
the MMU have a wired mapping to the physical address space, while if the
MMU is enabled, all addressing goes through the proper MMU PAR. This
don't incur any timing overhead at all. The time for passing through the
MMU is always present, and you cannot do anything about it, nor detect
it. And as I said above, the MMU must first translate the virtual
address into a physical address before the cache can take a shot at it.
(Incidentally, the hardwired addressing used if the MMU is disabled, is
to map the low 28 Kword of virtual space into the low 28 Kword of
physical space, but to map the last 4 Kword of virtual space into the
last 4 Kword of physical space, which is the I/O page. If you switch to
18-bit addressing, the MMU registers gets involved, but only the low 12
bits of the PAF are used, and of course in 22-bit mode all 16 bits of
the PAF is used.)
The MMU PAR is set up before the program can execute, and there is no
more overhead in accessing something through the D PARs than the I PARs.
You could possibly argue that the OS will need more time to fill in the
PARs if you have split I/D space, since that means you need to fill in
more registers.
The PDP-11 is not like more modern virtual address machines, where you
have a TLB, which is a cache for the MMU registers, and which is filled
in dynamically as the program proceeds. The PDP-11 have a very static
register set for the MMU, and those registers are already inside the
MMU. And the mapping is rather static as well.
Heck, you only have a total of 48 PARs at maximum to fill in. And that's
only if you use all eight PARs for both I and D space, and for kernel,
supervisor and user mode.
No, Jeromes "problem" really can only be attributed to cache conflicts.
It's not really a PAR0 vs. PAR1 problem, but a problem of both program
and data hitting the same cache lines.
With 8K cache, you have 13 address bits which select the cache line
(well, since the cache is really 16 bits wide it's actually 12 address
bits, A1-A12). A13-A21 is used as the cache tag. Any data hitting the
same cache line is matched on the cache tag, and if the tag don't match,
the cache is reloaded from memory. Otherwise data is served from the
cache directly.
So, if Jeromes program is in continous memory (which I assume it is,
since RT-11 really don't do much fancy work with the MMU), PAR1 comes
directly after PAR0 in physical memory, which means that the same
relative address within each PAR will hit the same cache line.
E11 will not have this problem, since E11 don't really implement the
PDP-11 cache. No point in doing that. However, E11 is running on a i386,
which happens to have exactly the same possible problem.
All machines with cache will display the same behaviour. If you are
smart, you can write a program that will tell you exactly how much cache
you have, how many levels there are, the TLB size (if you have one), the
associativeness of all caches, and also the timing of it all.
And all of this is done by probing the same thing Jerome just
discovered. :-)
I have such a program somewhere around here, but it's really something
that most people working with these things at a low level already should
know about.
>Shame you can try that (in F77) on a VAX or PC wher 32bit address
>space is the rule. I'd expect much different behavour..
>Till your task is paged out. ;)
It would be different, of course, in the sense that that program would
have different cache sizes, different associativeness of the cache,
would also have a virtual demand page system with a TLB, and a larger
natural word size, which would change the requirements of the program.
But we could easily create a similar effect on any machine. That is, the
speed of the program would be affected by where the data was placed.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.10/188 - Release Date: 2005-11-29
>
>Subject: PDP-11/73 booting!
> From: David Betz <dbetz at xlisper.mv.com>
> Date: Tue, 15 Nov 2005 19:56:03 -0500
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>I got my PDP-11/73 booting by connecting an RX02 drive to the system
>and using an RT-11 boot floppy. I've convinced myself that the 1.5mb
>of memory (two M8059s and a third party card) works and that the
>KDJ11-A CPU is working as well as the multi-function boot card
>(M8047) and the RX02 drive and controller (M8029).
>
>Unfortunately, I still can't access the RL01 drive. RT-11 sees the
>controller card but if I type "DIR RL0:", there is no indication that
Ah thats...
dir DL0:
the RL02 is accessed by the DL: driver. is there a DL.sys on the disk?
>the drive is even accessed. The disk seems to spin up and the ready
>light comes on on the drive but I don't seem to be able to access the
>drive from RT-11. I've also tried using a scratch pack and typing
>"INIT DL0:" but that doesn't work either. Does anyone have any idea
>what might cause this kind of behavior? Also, can anyone make me a
>bootable RX02 disk with the RL01 diagnostics on it? I can supply the
>blank disk?
Assuming the interrupt grant is good (no empty slots between the cpu and
the RLV controller. the cables are good and connected correctly. No fault
light and When the load bitton is in you get spin up and a white load lamp.
It should work.
Allison
On Nov 19 2005, 9:50, Barry Watzman wrote:
> I have a chart of paper tape hole patterns for all 128 characters,
and it
> shows the LSB (bit zero, although the chart numbers them 1-8) as the
edge
> hole on the 3-hole side, with the bits in order 0 to 7 (or 1 to 8).
>
> However, one question, this chart shows the high-order bit (parity
bit)
> punched for every character, no exceptions. Was that a standard
convention
> in sending ascii files to paper tape?
It was for DEC, at least with PDP-8s. I don't know about anyone else.
--
Pete Peter Turnbull
Network Manager
University of York
They are taken.
Michael Holley
----- Original Message -----
From: "Michael Holley" <swtpc6800 at comcast.net>
To: <cctalk at classiccmp.org>
Sent: Wednesday, November 30, 2005 7:59 PM
Subject: Free Popular Electronics Issues
>I have some extra issues of Popular Electronics that are available for the
>cost of postage. U.S. only. Shipping from 98052 but media mail is by the
>pound.
>
> 1978 Jan to Aug and Dec
> 1979 Mar and Apr
> 1980 Jan, Sep, Oct and Nov
> 1982 Mar, Apr, Sep and Nov
>
> Here is my Popular Electronics web page.
> http://www.swtpc.com/mholley/PopularElectronics/Popular_Electronics.htm
>
> Michael Holley
I have some extra issues of Popular Electronics that are available for the
cost of postage. U.S. only. Shipping from 98052 but media mail is by the
pound.
1978 Jan to Aug and Dec
1979 Mar and Apr
1980 Jan, Sep, Oct and Nov
1982 Mar, Apr, Sep and Nov
Here is my Popular Electronics web page.
http://www.swtpc.com/mholley/PopularElectronics/Popular_Electronics.htm
Michael Holley
...
Not funny VAX.
I still use and am a fan of IBM PS/2's. So are a couple others on
here. A few still use IBM RS6000 machines and one or two use
AS/400's. Please watch the generalizations...
-John Boffemmyer IV
At 09:20 PM 11/28/2005, you wrote:
> > BIG GOTCHA- you need to make sure your machine comes with
> not only the OS, but also the mashine-specific intermediate layer
> software. Unless you have a friend at IBM, they may be happy to
> give you a replacement in return for much cash, or they may do the
> snooty Maitre d' thing . . . and OS/400 is rumored to lock itself
> after a certain period of inactivity as well.
>
>You have found the reason why there are so many DEC fans and no IBM
>fans on the mailing list.
>
>vax, 9000
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.1.362 / Virus Database: 267.13.8/184 - Release Date: 11/27/2005
>
>Subject: Re: PDP-11/73 booting!
> From: David Betz <dbetz at xlisper.mv.com>
> Date: Wed, 30 Nov 2005 18:53:32 -0500
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>Well, I have bad news and good news. The bad news is that I was
>unable to fix my RL01 cable. I tried a few approaches to reconnect
>the pins I could see were disconnected and wasn't able to get it to
>work. However, the good news is that I was able to acquire another
>cable and that fixed the problem entirely. In fact, the PDP-11/73
>booted off the RL01 pack the first time I powered it up. I have three
>packs and was able to read all of them. One contains RT-11 V5.5,
>another is a TSX-Plus system disk but appears just to boot RT-11SJ.
>It does have lots of files on it with ".tsx" extensions but doesn't
>seem to boot TSX. The third is a blank scratch pack.
First, Congrats!
You need TSX.SAV and TSX also is built on RT11.
>I'm now in the market for a cable and breakout panel (cab kit?) for
>my RQDX3 controller so that I can connect an ST225 drive and an RX50
>floppy drive to my 11/73. I know it's possible to build one of these
>but from my experience with attempting to fix the RL01 cable, I don't
>think I want to tackle that project. If someone has a cable and
>breakout panel they'd like to sell please get in touch with me.
There isn't a "cab kit" for RQDXn. The cables were all internal
and you used RQDXn in one of the BA23/123 boxen. So you either need
a M9058 from a scrapped BA123 or a mostly torn up BA23 (micro PDP11
or microvax) you can pull the pannel from. You also need the little
switch pannel inserts from the BA123 to enable READY/OFFLINE and
Writeprotect.
You need:
1 50 pin female to female IDC cable (max length 18") RQDXn to breakout
1 34pin female to female IDC cable (max length 30") (RX50)
1 26pin IDC to card edge (RDxx)
1 34 pin IDC to card edge (RDxx)
If your not using either of those boxes then your doing what I did
which was to build something DEC didn't document. The cables are
seriously are trivial and not a big a deal like those breakout boards
and the switch pannels.
Having done this I know.
>Anyway, thanks to everyone who has given me help with this machine. I
>now have a working PDP-11/73 with 1.5mb of memory, an RX02 floppy
>drive and an RL01 hard drive and it's all working!
Sounds like mine. ;)
Allison
I'd look at what the resistors feed to- on my IRIS (as far as I can see) a resistor was smoked because multiple filter cap failures ^ ripple frequency with resultant lowering of reactive impedance, increasing current flow in this filter stage (between the outputs of the 5v rectifiers and ground, (.1?f cap -> 330 ohm -> gnd) and blowing the resistor. (at least that's what it looked like- the cap wasn't shorted and seemed to work properly under test)
