test-drb January 2009

test-drb@ccmp.vtda.org

218 participants
340 discussions

by ajp166＠bellatlantic.net

> >Subject: T-11 (was Re: PDP-11/70 cache memory) > From: "Bob Armstrong" <bob at jfcl.com> > Date: Thu, 01 Jan 2009 08:00:03 -0800 > To: <cctalk at classiccmp.org> > >>bfranchuk at jetnet.ab.ca wrote: >>PS. Now only if BOB could make a PDP 11 kit . :( > > I think it'd be fun too, and if somebody else made one I'd buy one, but as >a product - > > - there's no legal software you can run on the T11 (and no, RT11 isn't >legal!) Forth, CP/M68 could be compiled for it. I'm sure TinyBasic can be done >from Dave Dunfields TB in C. the nice part is anyone with a PDP11, LSI11 or sim (including Ersatz-11) can build an image and test it. > - there's no lights and switches front panel option for the T11 It a micro much like 8085 so yes it can be done. But a small SBC with 32kw ram, 2kw rom and some serial IO is a tiny thing. > - there's no source for T11 chips except to steal them from old hardware >like RQDX3s, etc > That's a bit harder but far from impossible. considering DEC used them in Falcon boards, and the the qbus slave (kxt21?), Vt240/241 series, and the storage hub (something mumble50). Allison >Bob

15 years, 11 months

T-11 (was Re: PDP-11/70 cache memory)

by bob＠jfcl.com

>bfranchuk at jetnet.ab.ca wrote: >PS. Now only if BOB could make a PDP 11 kit . :( I think it'd be fun too, and if somebody else made one I'd buy one, but as a product - - there's no legal software you can run on the T11 (and no, RT11 isn't legal!) - there's no lights and switches front panel option for the T11 - there's no source for T11 chips except to steal them from old hardware like RQDX3s, etc Bob

15 years, 11 months

new version of Overbite for Firefox

by spectre＠floodgap.com

For those people who are using my Overbite add-on to surf the friendly holes of Gopherspace, there is now an updated version that fixes a glitch with XML files (including SVG). This add-on includes a "dotless" filter to remove the trailing period that many servers send, such that they won't barf anymore. There are also some various small custodial thingies. This will be the last version for Firefox 2. http://gopher.floodgap.com/overbite gopher://gopher.floodgap.com/1/overbite -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Reality is when it finally happens to you, too. ----------------------------

15 years, 11 months

MSDOS/DOS OBJ file format compatibility

by mbbrutman-cctalk＠brutman.com

I've been working on my TCP/IP stack for three years now. It's in Borland Turbo C++ 3.0, which is capable of taking OBJs and making a LIB (library) from them. This is how I was planning to distribute my code for other people to use. A question came up today that I can't readily answer. If somebody is programming using Microsoft languages, will they be able to link against OBJs or LIBs I provide them? I have no idea if the OBJ or LIB format is standard and portable across the two vendor toolsets. If it is portable then I know I have to watch out for things like parameter ordering. But how does one express the concept of NEAR and FAR pointers in the different languages? Is there a guide or a cross reference somewhere? Maybe something buried in compiler docs somewhere? (The first target user is a *gasp* QuickBASIC user. I'd rather he program in C, but that's a different discussion.) Thanks, Mike

15 years, 11 months

Memory/cache on the 11/70

by bqt＠softjar.se

Guy Sotomayor <ggs at shiresoft.com> wrote: > On Dec 31, 2008, at 6:14 PM, Johnny Billquist wrote: >> Remember, SETASI did this on a hex card something like 20 years ago, >> if not more. Most of the area was probably memory chips, which can >> be reduced extremely much by now. > > Actually, they used some surface mount for the memory chips. The > memory was pretty dense on that board but certainly not the majority > of the area. Still, the level of integration today is much higher. So if it could be done 20 years ago, it should definitely not be a problem today. >> And to make a few comments on other stuff that's been mentioned. >> >> You don't seem to appreciate the speed of things on the memory bus. >> A read cycle form the MK11 was typically something like 600ns, and >> could be as much as 1200ns (when error correction was required), if >> I remember right. Write was just as bad, while modify was worse. The >> max speed possible is still much lower than 150 ns, which is what >> the CPU will run at when you have cache hits (assuming my memory is >> right). There is setups, handshakes and signal propagations on a big >> bus involved. > > I thought that was driven by the memory and not the memory bus. There > appear to be some minimum timings (50ns & 100ns pulses) but from what > I could tell from the docs, the speed was dictated by the MK11s and > not necessarily the memory bus. Of course there are deskew times as > well. I'll have to go into it in more detail though. There are built in limitation in the bus which always will cause it to be much slower than running against cache. This should be obvious when we talk about an asynchronous bus. You have a protocol with handshakes and acknowledges that goes back and forth for each memory access. And each of those phases of the protocol needs a minimum time. Of course, the 600ns minimum times of the MK11 are are partially because of the limitations of the MK11, but exactly how much you should blame each half for is unknown. After all, the access times for the memory chips in the MK11 box are not anywhere near 600ns. > If this were 15-20 years ago, I'd agree that speed would be a > principle concern, but space and power seem to be more important these > days. Given that this solution (just like the PEP-70/Hypercache) is > completely reversible I don't see a fundamental problem with this > approach. Me neither. As I said before, if someone wants to do it, I'll definitely not try to prevent it. But it's not something that I find particularly interesting myself. > I mostly do this stuff out of interest in preserving the systems in as > much of a runnable state as possible. All of the the 11/70s I > acquired over the past few years have been CPUs only. There have been > no memory boxes (or peripherals of any kind). I haven't been > particularly worried about this issue since I also managed to acquire > a fair number of PEP-70's & Hypercaches. But I suspect there may be > other people out there that aren't as fortunate and want to run an > 11/70 without having to have large numbers of racks. I don't worry > too much about space/power since I am restoring a 2065 after all and > 11's pale in comparison (but I'm also planning to do a memory > replacement for that too which is where I discovered the SSRAMs since > they are the perfect geometry for a '10). Well, both the 11/70s around here have enough memory as it is, so that if anything, it's the speedup that I'd be interested in. Power...? Well, we have two -2060s, as well as two VAX-8650 around as well. Compared to those, the 11/70s are nothing. :-) The biggest power consumer is the memory system of the DEC-20 by the way. It uses a linear power supply... Heavy as hell as well. :-) (I couldn't possibly talk you out of a HC-70/PEP-70 combo would I? Anything you might want in return?) >> 70ns memory will definitely be sufficient for whatever we would >> design. > > I plan on using 200Mhz SSRAMs 'cause they're relatively easy to > interface to. Of course, this is way overkill (5ns memory access > times) for this but they're cheap (~$8/ea and only 2 would be > needed). I probably won't clock it that fast. I figure something on > the order of a 40MHz base clock (25ns) would give me enough > granularity for any timing that would need to be done. Definitely overkill. But there is nothing wrong with overkill, as long as it don't cost a lot extra. >> I very much doubt that we'd have any problems getting it all into >> one or two cards. >> One advantage of replacing the cache is that then we'd definitely >> just talk TTL. No buses with drivers at all. >> Much simpler and cheaper from that point of view. > > The driver/receivers are my principle concern. I did find a bus > transceiver last night that's open-collector on one side and tri-state > on the other. That simplifies things *alot* if it's compatible > (though I suspect that with a 4-8" run of cables almost anything would > work). Now if I could just find one that was LVTTL on the tri-state > side I'd be happy (it would eliminate level shifters). :-) :-) >> Absolutely best would of course be if we could find drawings for the >> HC-70/PEP-70 combination, and use those as the basis for a design, >> and just improve by using current available technology. > > That would be ideal. However, does anyone have drawings for the > MK11? The most I could find was the tech manual on Bitsavers. I > mainly want to understand the transceivers a bit more. I think I have the drawings somewhere, along with a bunch of manuals that aren't on bitsavers either. One of these years I really should try to get it scanned, or something... (Along with a bunch of other documentation that I have lying around for various DEC stuff...) And as someone else said, the MJ11 drawings should also be good for the information you're asking for. (And yes, I've kept one real MJ11 around, just for nostalgia. But it's not hooked up.) I also have some third party memory boxes. I think they were made by Plessey. You could try find something from there as well. Johnny

15 years, 11 months

Language-specific CPUs was Re: uIEC/SD == AWESOME!

by shoppa＠trailing-edge.com

Chuck wrote: > On 1 Jan 2009 at 9:51, Rick Bensene wrote: > > > Yes, the Wang 2200-series machines used a microcoded architecture that > > implemented a BASIC interpreter as a native "language". > > Like an IBM 5150 without any disks? If we're talking about > "directly executing" shouldn't the hardware be so tightly wound up > with the language that reprogramming it (say, by replacing ROMs) to > host some other language is impossible? Otherwise, it's just a > conventional processor executing a stored program. What about, say, a Western Digital Microengine? It's a LSI-11 chipset but with different microcode to interpret P-code which by definition means UCSD Pascal, so in every real respect a language-specific processor in a way that a PDP-11/03 isn't. It's not like people just popped in different MICROM chips to go from a PDP-11/03 to a Microengine to a Alpha Micro WD16. At least, nobody I knew did. I've had Alpha Micros and Microengines and 11/03's at different times through the years and while it's obvious they all have WD chips I never did have the inkling to go muck about with the MICROM's. I doubt a 11/03 with a WCS would be enough to "become" a Alpha Micro or a Microengine. I always did my WCS stuff within the context of the -11 register set, for example. Maybe I was just restrictively unclever at the time. Tim.

15 years, 11 months

T-11 (was Re: PDP-11/70 cache memory)

by bob099＠centurytel.net

From: "e.stiebler" <emu at e-bbes.com> Subject: Re: T-11 (was Re: PDP-11/70 cache memory) >Bob Armstrong wrote: >> >> bfranchuk at jetnet.ab.ca wrote: >> >> PS. Now only if BOB could make a PDP 11 kit . :( >> > > I think it'd be fun too, and if somebody else made one I'd buy one, but as > > a product - > >There was/is a design out there from a guy (Peter McCollum) who made a >T11-SBC, and really got it working. He Wire-Wrapped it, but the >schematics are somewhere on the net. Somebody just has to sit down and >make a PCB out of it. Schematic here http://www.geocities.com/saipan59/dec/t11.jpg -- A prudent man foresees the difficulties ahead and prepares for them; the simpleton goes blindly on and suffers the consequences. - Proverbs 22:3

15 years, 11 months

Fairchild SYMBOL

by aek＠bitsavers.org

> Chapter 8 of "Advances in Computer Architecture" describes the SYMBOL computer, designed > and built buy Fairchild Camera, and operated at Iowa State. Only one was built. And that one is in the CHM collection. I have found some documentation for it, but no software.

15 years, 11 months

Memory/cache on the 11/70

by jam＠magic.com

> > Absolutely best would of course be if we could find drawings for the > > HC-70/PEP-70 combination, and use those as the basis for a design, > > and just improve by using current available technology. > > That would be ideal. However, does anyone have drawings for the > MK11? The most I could find was the tech manual on Bitsavers. I > mainly want to understand the transceivers a bit more. Hmm ... not on manx, either. I've got the MK11-B field maintenance print set (MP00523). I'll see if I can dig it out this evening. The MJ11 drawings would also show the transceivers. James Markevitch

15 years, 11 months

Memory/cache on the 11/70

by bqt＠softjar.se

Guy Sotomayor <ggs at shiresoft.com> wrote: > > On Dec 31, 2008, at 8:16 AM, Ethan Dicks wrote: >>> Skip the memory bus and the original cache. The original cache is >>> just 2 KB >>> of 2-way associative memory. If you set up a 4 MB cache, the CPU >>> can run at >>> full steam the whole time, with a cycle time of about 150 nS, if I >>> remember >>> right. >> Handy, since 70ns SRAM is easy to find. True. And 70ns is definitely fast enough. >>> It is more complicated, though. You'll have access paths from CPU, >>> Unibus >>> and four massbus controllers to deal with. But it should definitely >>> be >>> doable (heck, SETASI have already done it once). >>> >>> I might be interested in such a project myself, since the 11/70s we >>> have >>> around here still are on MK11 boxes. I could deal with PCBs and >>> design, but >>> I'm very short on time, as usual... :-( >>> No experience at all with FPGAs or any such fancy stuff. >> If such a thing were to be designed (I could participate in the design >> phase, but not drive it), I'd probably be interested in two, >> especially if the blank board was only a few hundred dollars. If it >> came closer to $1000, I'd really have to think about passing on the >> second one (I used to order multi-layer DEC backplane boards, and at >> the time, $500 was a good price for orders between q10 and q100, but >> things in the PCB market have changed radically). >> >> I'm in no hurry - my 11/70s are in storage and I won't be able to even >> pull them out to look at them in the next 90 days. > > The problem with replacing the cache is that it is composed of 4 hex > boards (M8142, M8143, M8144 and M8145). I haven't looked at the > backplane signals, but I'm dubious that it could be done with less. Correct. The cache and memory controller is a total of four cards. But unless my memory fails me, all the signals needed are actually located in just two of the slots. So you'd have to go with a two card solution. Either one card and paddles, or two cards with interconnects. > The advantage of just replacing the MK11 boxes, is that it could be > done with just one board. Depending upon signaling and such (and with > sufficient integration - ie FPGAs and SMTs) it *might* even fit on a > quad board vs hex. Oh, it could definitely be done with just one quad board. The memory bus is really simple. It's just that you won't get much of a speed gain that way, so it will mostly be a space and power save thing. Not at all as interesting, atleast not from my point of view. You can probably get it all in with through holes on a quad card even. The memory bus is really simple to interface. And since you'll keep it in the CPU box, and have the full 4 megs on one card, you can ignore all the requirements of the bus drivers for the memory bus as well. The 11/70 memory bus is otherwise designed for quite a long signal path. Total max was two cabinets full of memory boxes, or eight of them. That would get it close to ten feet. Power was accordingly. So, while not Unibus, there are drivers and terminators on that bus as well. (Actually, the terminators are the same as those small cards that terminate a massbus, if anyone ever disassembled one of those.) Remember, SETASI did this on a hex card something like 20 years ago, if not more. Most of the area was probably memory chips, which can be reduced extremely much by now. But, as I said, I don't find that exercise very interesting. > The other issue with not replacing the cache, is that the verilog to > implement this would *much* simpler (ie it can probably be completed > faster). True. Simple stuff is always faster to actually do. :-) And to make a few comments on other stuff that's been mentioned. You don't seem to appreciate the speed of things on the memory bus. A read cycle form the MK11 was typically something like 600ns, and could be as much as 1200ns (when error correction was required), if I remember right. Write was just as bad, while modify was worse. The max speed possible is still much lower than 150 ns, which is what the CPU will run at when you have cache hits (assuming my memory is right). There is setups, handshakes and signal propagations on a big bus involved. 70ns memory will definitely be sufficient for whatever we would design. Surface mount or through? Well, I don't really have much of a preference. Of course, through hole is easier to solder, test and repair, but they do take more space. And I can do either. My cad program have extensive libraries for all of it, so that's not a problem. I very much doubt that we'd have any problems getting it all into one or two cards. One advantage of replacing the cache is that then we'd definitely just talk TTL. No buses with drivers at all. Much simpler and cheaper from that point of view. Absolutely best would of course be if we could find drawings for the HC-70/PEP-70 combination, and use those as the basis for a design, and just improve by using current available technology. But of course, since I'm not offering to do this, except as a spare time project to aid in a community effort (unless I could actually make up for the time I would spend on it, and I somehow doubt there is a commercial case for this nowadays). So if anyone else wants to design a memory card to hook to the 11/70 memory bus, I definitely won't stop them, and might try to atleast give some helpful comments. Johnny

15 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb January 2009