- test-drb@ccmp.vtda.org - classiccmp.org

seeking DEC digital mps - microprocessor series monitor/control panel

by nigel.d.williams＠gmail.com

http://www.dvq.com/oldcomp/photos2/1k/dec_micro_panel.JPG I find this device quite fascinating (Intel 8008 plugged into a PDP-8 host), if anyone has one surplus I would be interested in negotiating. thanks. www.retroComputingTasmania.com

15 years, 9 months

7
11
0 0

Nuclear Data ND 6600

by legalize＠xmission.com

In article , Richard <legalize at xmission.com> writes: > > In article <E1P7wPP-0001ul-8h at shell.xmission.com>, > Richard <legalize at xmission.com> writes: > > > The Nuclear Data ND 6600 was some sort of laboratory PDP-11 setup. I > > have a terminal from such a system (very nice green keyboard). I'll > > upload some pics this week. > > However, I opened the case and was very surprised with what I found > inside the terminal. > > Its basically an empty box! Pics uploaded now: <http://picasaweb.google.com/legalize.slc/NuclearDataND6600> -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

15 years, 9 months

2
2
0 0

need teco suggestions

by legalize＠xmission.com

I need a TECO command suggestion that will fit in 3 lines of 18 chars each. It would be nice if I could have 5 chars leftover to have "TECO:" or "TECO " in there :-) -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

15 years, 9 months

4
6
0 0

FS on ebay: IMSAI 8080 Microcomputer and CompuPro S-100 Boards

by nick.allen＠comcast.net

For anyone interested... Just listed a fully functioning IMSAI and several compupro boards (Z80 8mhz CPU, floppy, hard drive and serial port controllers): http://shop.ebay.com/sdinet/m.html?_nkw=&_armrs=1&_from=&_ipg=50&_sop=1

15 years, 9 months

2
1
0 0

AT&T 610 terminal

by mark.kahrs＠gmail.com

My 610 burned up a few months back and I have no interest in reviving it. Is it a collectible? Or should I dispose of it at the local Goodwill?

15 years, 9 months

4
4
0 0

RL01/RL02 cables and terminators and unit plugs (was Re: PDP-11/34A bring up)

by ethan.dicks＠gmail.com

On 11/9/10, Tony Duell <ard at p850ug1.demon.co.uk> wrote: > The cables are differnet betwene the RLs and the RK06/07 (the latter has > all pins bet one (termintor power) connected That rings a bell (term power). > the former has rather fewer > wired), but AFAIK the terminator is the same (it terminates all signal > pins. I think at least one RL controller printset shows the exploded view > of the terminators with 'First used on Option/Model : RK06' specified. OK. That's a good detail to remember when setting up drives of either kind. One handy bit of trivia if you happen to have spare Unit plugs from the high numbers of an RK06/RK07 set is that they work in an RL01/RL02 if you mentally mask off 2^2 (i.e., an RK06/RK06 plug labelled "4" is "0" on an RL01/RL02). It's the same sort of switch/bulb housing, but one less bit going back to the electronics. We didn't do it often, but sometimes we were short some of the numbers and we did have a couple of RK07s and a drawer of random unit plugs. -ethan

15 years, 9 months

2
1
0 0

Gandalf

by tshoppa＠wmata.com

De writes: >> I am looking for info on a Gandalf LDS120 modem, specifically the >> serial port pinout. > In the division of irrelevant to the original question, I thought these > things were line drivers, not modems. I always thought they got lumped into "short haul 4-wire modems". They do have "DCD" lights on the front. I seem to recall that it's just a light and doesn't actually assert any RS-232 pins. But they could just be differential line drivers probably with isolation. 20+ years ago I'm sure I looked inside to see what's in there but I can't recall. I always thought they did some simplistic and almost certainly not Bell-standard FSK or PSK but that was just my impression, no actual evidence to back that up. Did the 4-wire screws on the back have labels of "+" and "-"? That would be a point in favor of them being line drivers and not modems (although some simple modems were in fact phase-sensitive). We used them between serial concentrators on different floors or between serial concentrators between nearby buildings. I note that there's no Gandalf directory at bitsavers. Gandalf certainly has a unique heritage not really being a "computer" company in the usual sense but for so many of us it was the gateway from terminal to the computer or between computers. I get the impression they were far more common at large academic institutions than at any commercial site. Tim.

15 years, 9 months

3
3
0 0

Old terms...

by bqt＠softjar.se

On 11/09/10 10:44, Roger Holmes<roger.holmes at microspot.co.uk> wrote: >> > From: Johnny Billquist<bqt at softjar.se> >> > >> > Gah. I have no idea what PPU mean, nor PP. > You're probably just not old enough. That is definitely true here. :-) > In the 50s the main processor was called the CPU (Central Processing Unit) to differentiate it from the various PPUs, (Peripheral Processing Units). The first machine I programmed, the IBM 7094 had a CPU and two PPUs, one to read cards and write the images to tape transports, which would then be switched over to the CPU to read, compile and execute the job and write the results back to another tape transport which then got switched to the other PPU which then transferred the tape image to a line printer. Thanks. That explains it. > Somehow now (when most peripherals have embedded processors which could be called PPUs) we seem to have stopped using the term. Yeah. It might have gotten lost in the inbetween years when computers were trying to get rid of, at the time, expensive peripherials (they were expensive enough without being their own computer). I only started playing with computers in those inbetween years. :-) Johnny

15 years, 9 months

1
0
0 0

S-100 board PCB planning

by lynchaj＠yahoo.com

Hi! Over the last couple of years several of us at N8VEM, S100computers.com, and others have been building S-100 boards. This summer we did a major update/respin cycle to the boards and made manufactured PCBs for many builders. For a while it seemed to satisfy the demand for DIY hobbyist S-100 PCBs but now the interest is starting to pick up again so I thought I would send an update to any S-100 enthusiasts on CCTALK. I will reorder/respin S-100 PCBs once the interest level gets to an economically viable level for a group purchase. Normally that is around 25-30 PCBs I know builders want which makes a cost at $20 plus shipping per PCB affordable for most builders. This compromise balance seems to work well and we've produced several S-100 boards this way. Here are the boards we've made so far: S-100 regular prototyping board (some remaining) S-100 buffered prototyping board (some remaining) S-100 backplane (8 slot plus utility circuitry - one left) S-100 IDE (hard drive, CD-ROM, CF, ATAPI, etc) S-100 parallel ASCII keyboard (just received a new batch of respin PCBs) S-100 4MB SRAM (Flash, etc) S-100 system monitor (similar to Jade Bus Probe but two PCB set - one or two remain) S-100 bus extender (with logic probe, indicator LEDs, etc) S-100 EPROM (SRAM, EEPROM, Flash, etc) S-100 IO (dual serial, USB, voice synthesis, etc) S-100 PIC/RTC All of these have gone through at least one or two internal prototype iterations plus one or more manufactured PCB orders. Since we respin the boards based on builder feedback obviously the later generations of boards tend to be "cleaner" than the earlier ones. This is an all volunteer amateur project so the builders *are* the developers, QA, testers, etc in addition to using the boards. There are four boards in active development and/or approaching manufactured PCB stage S-100 Z80 CPU (just ordered first batch of manufactured PCBs after two rounds of prototype build and test) S-100 Console IO (dual Propeller VGA, PS/2 keyboard, microSD, Ethernet, etc - first iteration prototype boards ordered) S-100 ZFDC intelligent floppy drive controller (Z80/WD2793 second iteration prototype board imminent) S-100 68K CPU (first iteration prototype boards ordered) Please note the above boards no longer *planned* they are actual boards in some form or another. There are several more in the planning stages but I won't waste your time with those since those plans change often. All of the schematics, PCB layouts, bill of materials, etc are available on either the N8VEM wiki or S100Computers.com website including build instructions for the most part. These are noncommercial Do It Yourself (DIY) hobbyist PCBs. They are not perfect nor is this a business. John's apt description from comp.os.cpm captures it well "Andrew Lynch (at N8VEM) see (http://n8vem-sbc.pbworks.com/) and I, are in the process of having a few commercial quality S-100 cards made for ourselves. If others are interested in obtaining a bare card, let Andrew or I know. Please note these would be bare cards, a schematic and that's it. Building the board and implementing CPM etc., you are on your own. This is not a project for first timers." In other words, if you want to play along that's great but this is purely "CAVEAT EMPTOR" and there are no assurances, guarantees, or warrantees on any aspect of the boards. Please this is offered as an information post to interested vintage/classic computer hobbyists not an invitation for flames and pointless criticisms. Please be courteous and keep those to yourself. As always, questions, comments and *constructive* criticism welcome. Thanks and have a nice day! Andrew Lynch

15 years, 9 months

5
6
0 0

Advin PILOT-142 programmer sw?

by chrise＠pobox.com

I was recently given an Advin Systems PILOT-142 device programmer... but of course no software with it. I downloaded Advin's Captain v1.34 software for XP from their website, where they claim support for the model -142 but after installing and launching the software, it reports that it does not work with the "revision" of my programmer. There are no revision or series marks on the unit other than the PILOT-142 sticker above the power switch... so I don't know what makes it different. Email to Advin says they have NO software that supports the -142 even if their website says otherwise. In any case, I'm looking for anyone that might have DOS or Win software for this older beast. It would be a nice unit for burning 2716, 2732 and a number of old PALs that I would like to do. Chris -- Chris Elmquist

15 years, 9 months

3
4
0 0

Ten P112 kits-a-cookin

by dgriffi＠cs.csubak.edu

The leftover P112 parts have arrived in Portland. We're now working out what more needs to be bought to make kits. There will be ten kits. This means that if all the preorderers take one, the last one who put down for a preorder will not get a kit. I think I've already refunded your money anyhow. If one of the ten declines to take a kit, the will be offered to you (you know who you are). I'll keep the list informed on further developments. -- David Griffith dgriffi at cs.csubak.edu A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?

15 years, 9 months

1
0
0 0

PDP-11/34A bring up

by chrise＠pobox.com

I am the new keeper of the PDP-11/34A that Jack Rubin rescued a while ago and wrote about here, http://decpicted.blogspot.com/2010/01/pdp-1134a-data-systems-design-dsd-880… I took it on a road trip from Chicago back to St. Paul after VCFMW in September. I've been doing a lot of cleanup on it and finally got to the point where I could power it on (just the CPU box) this weekend. I think now I need to learn about Grant Continuity ;-) There is a M9302 terminator installed in the last slot (left most when looking from the front of the machine) and also an M9312 in slot 4 (amoungst the CPU and cache cards). Two of the original boards are removed from the backplane... the DSD 808830 controller and the DILOG DU130 tape controller. They were in slots 12 and 13. I then also have an RL11 on hand but it is not currently installed in the machine. When I power up the machine, it immediately lights the RUN light on the KY11-B programmer's console. No matter what I do from that console, I cannot get it to exit RUN or print anything to the serial terminal. However, if I remove the M9302 terminator (a trick I found on some web page), then sure enough, I can HALT it, the RUN light goes out and I can do CTRL+BOOT and the serial terminal will spring to life with a register dump and the '@' prompt. I'm pretty sure that my problem is the empty slots 12 and 13 where boards used to be and should now have Grant Continuity cards installed instead... but I am curious why pulling the M9302 makes it "work". What is the mechanism at play there? I also suspect that I may have to look at the backplane wiring for slots 12 and 13 to put back whatever DMA jumpering might have been modified for the two cards that used to be there-- or, at least for one of them as I can probably put the RL11 into one of those slots and it requires DMA. Chris -- Chris Elmquist

15 years, 9 months

7
10
0 0

Dell Refurbished DEC (?!)

by robert.jarratt＠ntlworld.com

Just noticed a number of items like this one http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=260689944041 appear on eBay. These are strange listings. First I would be very surprised if Dell refurbished vintage DEC stuff. Second it is listed as refurbished but is also described as being in New condition. Has anyone ever dealt with this seller? They seem to have good feedback. I wouldn't buy at that price in any case, but just curious I suppose. Regards Rob

15 years, 9 months

2
1
0 0

Help with testing Sun CP1500-440

by auringer＠tds.net

Hi all, I recently acquired a SPARCengine 440, which is a CompactPCI form factor SBC. I don't currently have a cPCI chassis in which to test this thing. Normally I would just hang onto this and wait for a chassis to present itself, but I would like to know if the card works before spending resources on the chassis. Is there someone that would be able to help me out with some testing? I think I could make it worth your while. Thanks, -Jon

15 years, 9 months

4
15
0 0

Amstrad 3in disc drive troubleshooting

by classiccmp＠philpem.me.uk

OK, this is seriously weird. I have two Amstrad 3-inch disc drives: an EME-156, and an EME-231. Both drives will spin up, select and generally "work". For varying values of "work". On both, the "activity" (selected, whatever) LED is stuck on at half-brightness, but switches to full brightness when the drive is selected. For reference: both drives are showing the exact same symptoms. I can select the drive, spin the motor, and seek around the disc. Writing seems to work (more or less) -- when WR GATE goes low, the coils of the head are driven to ~10V with smaller positive and negative pulses (sort of like an exponential curve, synchronised with the falling edge of WRDATA). When WR GATE goes high again, the head voltage falls back to about 2V. When I try and read anything, the head shows no response whatsoever. No pulses on either side of the head at any amplitude (measured with a 1:10 probe on a Tek TDS2024B). Similarly, RD DATA shows no pulses either, except for a brief glitch (2.8us or so) when the drive is selected. The drive controller ASIC also gets rather hot.. like, too hot to touch. I've confirmed that the power is correct -- 12V and 5V have been applied to the correct pins. I'm using "new old stock" Amsoft discs which I bought from an ebay seller. No idea if they're good or bad, but they arrived in shrink-wrapped side-opening plastic boxes and were apparently "Made in Japan." My current suspects are: - Discs. The discs aren't actually magnetically coated in any way, or the coating has failed in some way. Catch is, I don't have a known-good disc to test with. - Heads. Dirty, out of alignment or otherwise completely pooched. Can anyone suggest some things I could check, or are these drives likely to be toast? Thanks, -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

15 years, 9 months

6
22
0 0

Crucifixion (was Re: Fragility in the floppy world (was Re: TRS-80 Model II Manuals))

by roger.holmes＠microspot.co.uk

On 7 Nov 2010, at 18:00, cctalk-request at classiccmp.org wrote: > > Message: 7 > Date: Sat, 6 Nov 2010 21:15:55 +0000 (GMT) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: Fragility in the floppy world (was Re: TRS-80 Model II > Manuals) > To: cctalk at classiccmp.org > Message-ID: <m1PEq7C-000J48C at p850ug1> > Content-Type: text/plain > >>>> Oh, go ahead... But I beleive that cucifixion has never been used as a >>>>> suicide method. >>>> No. I've tried it dozens of times; there's just no way you can hammer in >>>> the last nail. >> On Fri, 5 Nov 2010, Tony Duell wrote: >>> I have this image of 4 of those butane-powered nailers used by builders >>> suitably arranged nad with a remote triggger facility. You get your arms >>> and legs in the right places, somehow press the switch and bang... >> >> You might be able to get away with one of the Sears "Nextec" cordless >> electric hammers. > > Except that I am in the wrong country for this. > >> >>> No I am NOT thinking of trying this. >> So, the technique remains untested. > > Do you _really_ want me to try it? Definitely not, for one thing you would not be able to report back the result of the test if successful, only if it failed. A bit like testing the I/O instruction that a torpedo's processor issues to explode its charge, and the code it executes afterwards. The Q.A. department of course would insist that the absence of a detonator and charge might affect the result of the test so must be connected up. We do get into some weird discussions don't we, like guns. What's next? Using classic computers for "sex and drugs and rock and roll"? World domination? Extermination of parasites? Building of DNA molecules to breed a super intelligent organism which will then decide to eliminate what it regards as parasites, the human race? If you must go off at tangents, please at least change the subject line! Roger Holmes

15 years, 9 months

9
10
0 0

Virtual memory

by bqt＠softjar.se

On 11/06/10 02:03, Brent Hilpert<hilpert at cs.ubc.ca> wrote: > Flogging a dead horse perhaps, as I believe the discussion is simply a > matter of differing definitions of the phrase "virtual memory", but > let's try a different approach: Nothing like flogging dead horses... :-) > Suppose we have a machine which at the instruction level provides > 32-bit addresses, that is, it presents a 32-bit address space (4GB) to > the user. However, there is only 1 MB of physical RAM memory in the > machine. That is one scenario, but definitely not the only one. Part of the problem is that people seems to want to limit them self to this scenario, and of course, if you start at that end, then you will more or less always end up in the same place you just do here. :-) > Without trying to go through the whole history of OS development > (leaving out things such as overlays, shared libs, etc.), and without > accounting for memory required by the kernel/OS for simplicity, > consider several scenarios: > > - 1. User addresses map directly to physical addresses. > User address 0 is physical address 0. The user address space is > obviously > limited to 1MB or less of memory and the user will be aware of such > if an > attempt to address beyond that is made. Yes. And if you have several processes, they are all aware of each others memory space, and care must be taken that they do not wander outside their own confinements and clobber things in the system (including the OS). Programs must be written to be memory aware, and either PIC, or else linked to run at a specific address, since there is no virtual memory. > - 2. We add an MMU to map addresses. > Multiple user address spaces may exist and can be mapped to different > areas in physical memory. User address 0 may or may not ref physical > address 0. > A user is still aware of a limited address space dictated by the 1MB > of > physical memory. The total of the user address spaces cannot exceed > 1MB. Indeed. And it can be an arbitrary lower limit than 1 MB as well. And at this point, programs can be written to not be memory aware. All programs can be written without consideration to what addresses they use. All can be linked to start at the same address, and run in parallel. They are not aware of, nor do they see other programs memory space. They can be PIC, or position dependent. They can clobber all their memory, and the system itself is not affected. > - 3. We add swapping-to-disk. > The system as a whole is no longer limited to 1MB of memory, there > may be > multiple user address spaces totalling more than 1MB of memory. Each > user > however, is still limited to a max of 1MB of address space, i.e. > each user > is still aware of the limited physical memory. Right. Adding swap does nothing more than grow the capacity of the system total. For a single process, it is invisible. > - 4. We add address-faulting, demand-paging - whatever one wants to > call it. > The user address space is no longer limited by physical memory. The > user can > hit any address in their 32-bit space and (magically) find a valid > memory > location there. More physical memory can be added (or removed) > 'underneath' > the user(s) without their awareness. Except, or course, the OS can still limit you to use less than 1 MB. Adding paging does nothing for the individual program as such. It is totally invisible. You might argue that it gives you the possibility to use more memory than physically available, and that is true, but that is at the discretion of the OS. To get more memory, you will need to call the OS to request more memory, and the OS can allow or deny this request. Same as in #2 above. > By the nomenclature I grew up with or suffer under, the term "virtual > memory" only applies in scenario 4, although "virtual addresses" could > be said to have been introduced in scenario 2. The difference between 2 and 4 is only that the OS *can* allow you to use more memory in scenario 4, not that it necessarily will allow it. > Or, scenario 4 was my understanding of the *commonly-agreed-upon > application* of the phrase "virtual memory", although I would not argue > that in a very general sense it may be applied to scenario 2 or 3. The difference between 2, 3 and 4 is actually extremely vague. The only actual difference is that the OS *can* allow you to use more memory. But let's say that the OS will not. Does that suddenly mean that you don't have virtual memory, even though it is indeed using page demand loading and all that fancy stuff? And this also totally ignores the scenario that exists under the PDP-11, and which started this thread. What if you have more physical memory than can be addressed by virtual memory? That's a whole different ballgame, and is not covered by any of your scenarios... All in good spirit. :-) Johnny

15 years, 9 months

2
1
0 0

Core memory repairs, part 2.

by jdr_use＠bluewin.ch

I spend some more time on the severely defective 8/L core stack I have. First I repeated the diode checks and wielded out all diodes that were more than 40mV away from the .55 V forward voltage that seems to be standard. Total number of defective diodes : 29 . Still cannot figure out why so many diodes were dead/shorted. Also repeated the inhibit / sense wire checks : 1 sense wire open. 1 sense wire high ohmic. ( 200 ohms ) 1 inhibit wire high ohmic ( 250 ohms ) Normal value for sense / inhibit wires would be around 15 ohms. I then opened the stack by cutting through 128 X/Y wires and removing 256 wire halves... There were several old repairs, covered with some ceramic substance, luckily all on the edges of the core mats. The high ohmic wires were due to this old repairs, after scrubbing off the ceramic stuff and resoldering the connection the high ohmic sense wire was restored to its nominal 15 ohm value. I still have to fix the other wires, ( i.e. 512 wire halves to remove...) and reassemble the stack, but it looks like core memory repairs are possible by amateurs. Material needed : - high powered, but comfortable, microscope. - SMD pencil soldering iron. The smallest I could find, and it was still too big. - the smallest solder I could find, still way too big. The other core stack, with the one single bit error, is still closed, but by swapping sense wire I was able to confirm that the error is indeed in the stack. Jos Dreesen

15 years, 9 months

2
1
0 0

CPU scrap

by teoz＠neo.rr.com

While browsing on ebay lately I noticed CPU scrap going for quite a bit of money, for example: http://cgi.ebay.com/1-lb-Lot-high-yield-CPU-gold-scrap-recovery-486-/220690… Seems like 486 era chips (ceramic) are getting melted down for gold, and those poor PPros are going to be rare as dodo birds in a decade. Kind of makes me wonder if anything is going to be around from the 90's computer era in a dozen years. How much of the earlier stuff was saved from melting because gold was only worth $350 an ounce in the booming 90's compared to $1390 in the current depression? TZ

15 years, 9 months

13
29
0 0

Terak Boot behavior?

by derschjo＠mail.msu.edu

Hi all -- I've made a small bit of progress with my new Terak. The power supply seems to be working fine, and after going over everything and cleaning the old crumbly foam out, cleaning edge connectors, and reseating everything it now gives the impression that it's trying to boot. (And Al's been kind enough to send me a few images from the CHM, so I have something to try and boot!) However, I've never actually seen one of these in action before, so I have no idea what the expected behavior actually is. I currently get nothing on the display (the CRT is lighting up and if I turn the brightness up I can see a raster, so I know it's at least minimally functional) and I get no sounds from the speaker. The drive seeks back to track 0, pauses for 1-2 seconds and then and seems to briefly access the disk for another second. Then, nothing. Can anyone who has used one of these before tell me if this is anywhere close to expected behavior? Is it possible to get a serial console on these (and is there anything like a PDP-11 ODT prompt?) Thanks, Josh

15 years, 9 months

2
1
0 0

RTEM-11 Questions

by jhfinedp3k＠compsys.to

I am attempting to enhance a program which runs under RSTS/E, RTEM-11, RT-11 and TSX-Plus. Thus far, I have managed to support these enhancements for all but RTEM-11 due to the lack of documentation on RTEM-11. When I requested help with supporting such programs under RSTS/E, John Dundas provided a reference document which cleared up many questions. Does anyone know of a document (and its link if it is on the internet, especially at bitsavers) which describes the support provided by RTEM-11 for programs which also run under RT-11? From the comments that I have seen, the RT-11 operating system is run under RTEM-11 with special "hooks" to interface to RTEM-11. If my understanding is correct, then all of the RT-11 EMT requests supported by an RT11SJ monitor will also be available when running under RTEM-11. There are also two other specific questions that I suspect have a simple answer: (a) How much memory does a user program have which runs under RTEM-11? My assumption is that a user program has approximately the same size of memory available when running under RTEM-11 as it would when running under the RT11SJ monitor on a PDP-11 with 64 KBytes of physical memory which usually (when no additional device drivers are present) ends up being approximately 48 KBytes or an address range from 0 to about 120000 octal. (b) Whereas RT-11 actively supports the ability of device drivers to be LOADed and UNLOADed at any time based on which devices are in active use, RSTS/E and TSX-Plus require the device drivers of any device that is active to be LOADed at all times. It would be an assumption on my part, but I tend to assume that under RTEM-11, any available devices are already LOADed by the actual operating system that controls the CPU. Specifically, if a user program performs the .DStatus RT-11 EMT request for an available device, the 3rd word of the device driver information will always be non-zero which specifies that the device driver in question is always in memory and that a .Fetch RT-11 EMT request would be redundant. Can anyone provide any documentation sources? If anyone knows the answer to the approximate size of memory available to a user program running under RTEM-11 and / or the answer concerning the LOADed status of a device driver, it would be greatly appreciated. Jerome Fine

15 years, 9 months

1
0
0 0

PDP-11 firsts?

by bqt＠softjar.se

On 11/06/10 02:03, ard at p850ug1.demon.co.uk (Tony Duell) wrote: > >>>>>> > >>> > > The Philips P800 series has the PC as a general register (register 0). >>>>> > >> > >>>>> > >> > Could you use it like any other register? >>> > > There were some restrictions. I don't think you could shift it (at least >>> > > ont on the P850). But for many instructions it was just another register. >> > >> > Cool. So you could add to it, index by it, and so on? > I think so. I can't find my programemrs pocekt guide fo the machine at > the momnet. But I am pretty sure that register 0 could often be used like > any other register. Ok. Nice. > There is at least one oddity. There are no autoicrement/autodecrement > adressing modes on the P800s. However, in some cases, if you use the PC > in some instructions it is autoincrements. For example the 'immediate' > addrtessign mode isessentialy a (PC) operation (i.e. take the word > pointed to by register 0) and has that bit pattern. But for obvious > reaosns the PC is autoincrements then. The PDP-11 actually pulls that trick on a few addressing modes as well. Addressing mode 6 and 7 autoincrement the register if it is the PC, but not for other registers. (So a thing like MOV FOO,R0 is encoded as MOV x(PC),R0 .WORD .-FOO and the PC should obviously be incremented again here, but x(Rn) does not exist as a variant with autoincrement of the register.) >>> > > I guess the P800 wasn't totally ortogonal but it was a lot more >>> > > orthogonal than many other machines. >> > >> > Indeed sounds nice. When did the machine appear? > My P850 CPU service manual is copyright 1972, which alas puts it after > the PDP11, but I thoguht the series was around a bit before that. Hmm. Maybe still a first for the PDP-11 then...? :-) >>>>>> > >>> > > What do you mean by condition codes here? >>>>> > >> > >>>>> > >> > The four low bits of PSW. >>> > > Err... I don;t think that's helpful. Quite a lot of machines with a >>> > > status register have a 'low 4 bits' of it:-). But that doens't make them >>> > > condition codes. Similarly uf you hapopen to implement the same >>> > > functionality using other bits of a status registers, doesn't that make >>> > > them condition codes? >>> > > >>> > > What I was asking was what fucntionality do you require of these >>> > > condtiion codes other than there being conditional jumps on carry, zero, etc? >> > >> > Sorry. I was just being lazy, and trying to explain condition codes by >> > referring to what they are on the PDP-11. >> > >> > To try and be more specific then: condition codes are bits that are >> > set/reset as a result of operations performed by the processed, and upon >> > which you can the make conditional branches/jumps on. > Now the P800 has a very odd way of doing this. There is a 2 bit status > registers. It is set differnet ways according to the results of some > instructiuos (for example, an arithmetic instruciton will set it one way > if the result is 0, a differnet way if there's a carry out, etc). I/O > operations set it one way for device ready, another for certain errors, etc. > > The condtional branches have a 3-bit condition field. You can branch on > the status beits being any particualr value (00, 01, 10, 11), them not > being one of 3 values 9I forget which one is omitted) or 'always' Sounds slightly different than the condition codes of the PDP-11 then, but not really like the immediate test and do instructions like the PDP-10. Closer to the PDP-11, it would seem. Johnny

15 years, 9 months

1
0
0 0

Virtual memory

by bqt＠softjar.se

On 11/06/10 02:03, "Chuck Guzis"<cclist at sydex.com> wrote: > On 5 Nov 2010 at 15:09, Brent Hilpert wrote: > >> > By the nomenclature I grew up with or suffer under, the term "virtual >> > memory" only applies in scenario 4, although "virtual addresses" could >> > be said to have been introduced in scenario 2. > My original definition was that "virtual memory" was the ability of a > system (hardware, software, whatever) to fool a program into thinking > that there was more memory present than was physically the case. > > Johnny (and please forgive me if I got this wrong) tied it into the > ability to present each user with a address space, such that two > users could use the same address space, but have different data. Key > was the claim that a system with more physical memory than the user > could directly address still qualified as virtual memory. > > I don't tie virtual memory into paging or even to multi-tasking or > multi-user, although I'll concede that paging is a way (albeit > rather simple-minded) to implement it. The Burroughs B5000 didn't > employ paging and yet I think few would argue that it did not > implement virtual memory (and quite possibly the earliest commercial > use of it). Yeah, you got more more or less right. Virtual memory according to me (well, I got the definition from DEC) is the appearance of memory that is your "own" although you in fact are running on a system with many processes running concurrently. You can do anything with your memory, and it will not affect anyone else. It's like your own sandbox. You can do anything in there. Obviously, this is not really tied into paging, nor multi-tasking (you can have this with just one process, still protecting the OS from you). Obviously, I do not tie memory sizes on either end to what virtual memory is. You know, things like overlays are actually a form of paging as well, and is a solution to allow you to have more memory used than physically exist in the computer, and yet it don't require virtual memory to implement this. (Heck, I just came up with an example of paging and memory sizes that is totally disconnected to virtual memory, or page tables, or anything close to that.) Johnny

15 years, 9 months

1
0
0 0

S-100 board PCB planning

by lynchaj＠yahoo.com

http://classiccmp.org/pipermail/cctalk/2010-November/293791.html >Hi Andrew. > I am restoring a Northstar Horizion. Would any of your boards be suitable >substitutes for the original NS ones? > > >Regards >? >Rod Smallwood Hi Rod! Thanks! The boards would likely work in a NorthStar Horizon as it is a fairly normal S-100 system. The boards are designed to be strictly IEEE-696 compatible so either they would work as is or require some minor adjustment. They are not strict NorthStar replacement parts though. They would compliment a NorthStar system nicely I think but it would depend on the board and how you use it. It is hard to say without knowing your specific application though. Allison covered the topic pretty well in her commentary. My recommendation is to check out S100computers.com and see the documentation on the boards and see if this would interest you. There are a lot of photos, explanations, and videos of the various boards in action. http://classiccmp.org/pipermail/cctalk/2010-November/293798.html [Alexandre Souza] > Andrew, I'm **VERY** interesting in knowing more about S-100 boards. How >much would it cost? > The S100computers.com and N8VEM S-100 boards are an all volunteer amateur run project. They are roughly at cost for the PCB manufacturing. They are $20 per PCB with $3 shipping in the US and $6 shipping elsewhere. These are group purchases of boards for hobbyists by other hobbyists. I am not soliciting sales for the boards. What I am asking is if hobbyists are interested in getting these boards to contact me and tell which ones they want. I will order/reorder boards when the "waiting list" for any given board gets large enough to warrant an order. This is not a business as I am trying to organize a group buy of the boards. John and I are ordering boards for ourselves anyway so I thought to offer to the community if there were other interested hobbyists. There are about 50-60 S-100 builders on the private distribution list now. All of the boards are documented at S100computers.com and the N8VEM wiki. The design information for hardware, software, schematics, PCB layout, parts list, build instructions, etc are freely available and posted online. If you can't find it please ask and hopefully I'll update the website. I hope this helps. Thanks and have a nice day! Andrew Lynch

15 years, 9 months

2
1
0 0

FFS Sun monitor

by rdawson16＠hotmail.com

From: rdawson16 at hotmail.com To: innfoclassics at gmail.com Subject: RE: FFS Sun monitor Date: Mon, 8 Nov 2010 16:50:16 -0600 Paxton's got the scopes too. Its good to see stuff go to a good home. Fellow packrats unite! Randy From: rdawson16 at hotmail.com To: innfoclassics at gmail.com Subject: RE: FFS Sun monitor Date: Mon, 8 Nov 2010 16:24:07 -0600 Hi Paxton, Its yours. Call me and we will arrange things. I need to leave here by 5PM tomorrow for a ham meeting... I also have a couple of oscilloscopes, low end, probably 5 MHz bandwidth a Sencore and a Heathkit, 5 inch CRTs if anybody wants them. Randy 503-352-4612 > Date: Mon, 8 Nov 2010 13:46:42 -0800 > Subject: Re: FFS Sun monitor > From: innfoclassics at gmail.com > To: rdawson16 at hotmail.com > > On Mon, Nov 8, 2010 at 1:54 AM, Randy Dawson <rdawson16 at hotmail.com> wrote: > > > > Its large and heavy 19" ... > > > > Works fine with vga at hi res,and has attached cables for the sun. > > > > Its going to the recycle unless you guys want it. > > > > Randy > > > > > Hi Randy, > > I am interested in the monitor. I have a couple of Sun boxes that do > not have a monitor. > > I am in Eugene at the moment but going back to Astoria tomorrow, Tuesday. > > I could stop by tomorrow afternoon on my way through if it is still available. > > Paxton > > > > -- > Paxton Hoag > Astoria, OR > USA

15 years, 9 months

1
0
0 0

Virtual memory

by bqt＠softjar.se

On 11/05/10 19:13, "Chuck Guzis"<cclist at sydex.com> wrote: > On 3 Nov 2010 at 20:47, Johnny Billquist wrote: > >> > Ok. So, a program would think it addressed a memory space, which was >> > it's own, and the addresses it used would in no way related to the >> > actual physical memory it ended up referring to. I'd call that virtual >> > memory. Although, having to map the whole virtual memory as one chunk >> > to physical memory makes it a little more work, end less flexible than >> > having pages. And it pretty much prevents you from ever being able to >> > share memory in a reasonable way between processes. > Well, not really. I refer you to the CDC 7000 SCOPE 2 operating > system. There's a users' manual on bitsavers, but I suspect the > design notebooks have long vanished from the face of the earth--so > there's no documentation on the innards. I tried to find any manuals on bitsavers, but I can't see anything about a CDC 7000 there... But while I can see that doing shared memory would be possible even with a single mapping between virtual and physical address space, it would mean you need to copy data between different locations between each context switch, which would be rather heavy. > At any rate, the CDC 7600 OS people had a peculiar problem. On the > 6000 series of machines, PPUs are free-range; they have access to all > of memory and at the time (say, 1968), comprised most of the > operating system--there was almost no CPU code involved. You'd stick > a request into your own location 1 and PP 0 would see it and detail > off the work to the rest of the PPs. Very cool--you never gave up > control of the CPU unless it was to yield to the job scheduler. Gah. I have no idea what PPU mean, nor PP. But it sounds like what you describe now would not be virtual memory. If each process have access to all of the memory, then you'd not have your own address space. Instead you'd have to make sure you kept within your bondaries. Hopefully the hardware can assist with that, but maybe not. But that is still something else. It's basically just talking about physical memory. But I might very well totally be misunderstanding things here, since (as I said) I don't know what these acronyms really mean. > But this wasn't possible on the 7600, as each PP was assigned its own > hard-wired slot in CPU memory and was unable to access anything but > that. So the 7600 PPs were detalled off to I/O only. (Now, I'd call > that memory-mapped I/O--you want to to talk to a certain I/O > processor, you communicate with it through a hardware-fixed location > in memory.) Which left the CPU to handle OS tasks such as job > scheduling and file management. A whole new can of worms, as SCM > (the memory that a program could execute from was very fast, but > somewhat limited). To me, the difference between shared memory I/O and memory mapped I/O is about how the notification comes across between the subsystems. Is the slave triggered by a write to the memory, or does the slave poll the memory location. If the slave polls the memory location, then I'd called it a shared memory design. If the slave gets triggered by a write to the memory, then I'd call it memory mapped I/O. And what you describe here could further be called I/O channels, I think, in IBM speak. Basically, separate processors running their own code, which can do limited kind of stuff, mostly related to I/O functions for the main processor. Some of these designs even allowed you to place the "program" to be run in shared memory, and then kick off the I/O processor to do the work, and it signalled back when it was done. But I digress... :-) > A small permanently-resident "kernel" to handle PP commination and > task swapping was written, but job processing, file management, etc. > was performed for each job with a sort of matryoushka doll setup of > overlapping field lengths. In other words, a user program was > completely enclosed within the record manager which was completely > enclosed within a buffer manager which was completely enclosed within > the job supervisor for that job. So all user memory was shared with > successively higher privilege level tasks, differing only at what > location their respective location 0s were assigned to physical > memory. Ah, yes. That is also shared memory between different processes, but in a somewhat limited hierarchical way. You could for all OSes say that any process is always sharing it's memory with the operating system. :-) > The 7600 also had a bulk core "LCM" which couldn't be executed from, > but served for swapping and data storage. > > As far as piecemeal swapping, I'll leave that for another time when I > discuss the CDC Zodiac operating system (1970), something for which I > suspect no documentation survives. Sounds like fun... Johnny

15 years, 9 months

2
1
0 0

Gandalf

by tshoppa＠wmata.com

> I am looking for info on a Gandalf LDS120 modem, specifically the serial port pinout. I recall it's just 2, 3, and 7, i.e. no hardware flow control, and probably not even DTR/DSR. Now whether 2 and 3 have to be swapped...well I always just tried it both ways until it worked :-) And it's 4-wire leased line on the analog side, right? So no ring detect etc. either. Tim.

15 years, 9 months

2
1
0 0

Any ideas what chip goes in this socket?

by ard＠p850ug1.demon.co.uk

The device [1] that's currently all over my bench has an empty 28 pin DIL socket on one of the PCBs. It's alongside a 27C256 EPROM and 43256 RAM, and has a similar pinout. In fact the pinout is the standard JEDEC one for 28 pin memory devices (with A13 on pin 26, WE on pin 27, OE on pin 22, etc) with one exception. Pin 1 is not A14, it appears to be an output, linked to an interrupt pin on the 80C85 that links to the aforementioned memory devices and this socket). Oh, and to an input port pin. Any ideas? My first thoughts were an E2PROM or simular, with a ready output on pin 1, or a RTC/memory device with an interrupt output on pin 1, but I can't find any obviuos candidates. [1] A telephone network simulator. OK, it's not a classic computer, but I will be using it to test and demonstrate classic computer modems, it's well over 10 years old, and contains 6 microprocessors... -tony -------------------------------------------------------------------- myhosting.com - Premium Microsoft? Windows? and Linux web and application hosting - http://link.myhosting.com/myhosting

15 years, 9 months

2
2
0 0

Gandalf

by two_bit_mem＠yahoo.ca

Hello I am looking for info on a Gandalf LDS120 modem, specifically the serial port pinout. TIA Marty

15 years, 9 months

2
1
0 0

FFS Sun monitor

by rdawson16＠hotmail.com

Its large and heavy 19" ... Works fine with vga at hi res,and has attached cables for the sun. Its going to the recycle unless you guys want it. Randy

15 years, 9 months

4
7
0 0

Weird discussions, was Crucifixion (was Re: Fragility in the floppy world (was Re: TRS-80 Model II Manuals))

by dm561＠torfree.net

Date: Mon, 8 Nov 2010 08:28:03 -0800 (PST) From: Cameron Kaiser <spectre at floodgap.com> Subject: Re: Weird discussions, was Crucifixion (was Re: Fragility in the floppy world (was Re: TRS-80 Model II Manuals)) > > I once dated a girl who was a DEC geek (she grew up > > around PDPs), and she wanted to have, erm, "physical > > relations" atop my VAX 8700. > > Now we know the "real" reason the Cray-1 was C-shaped. > > A whole new classification of computers! > > - if you can have physical relations inside it, it's > a mainframe > - if you can have physical relations on top of it, > it's a mini-computer > > - if you can get involved with someone who would > like to test those characteristics you're amazingly > lucky Dr Pepper -> keyboard +++++++++++++++++++++++++++++++++++ Not to brag, but in my experience the Cray-1 would be much harder to find (and maybe more desirable in the long run...)

15 years, 9 months

1
0
0 0

Virtual memory

by roger.holmes＠microspot.co.uk

> From: Dave McGuire <mcguire at neurotica.com> > >>> I'm not familiar with the B5000 implementation (did I miss it in the >>> thread already?), but I did try to avoid restricting the def to that >>> of paging. >> >> The B5000, circa 1961 was an amazing bit of equipment. Read about it >> here, then compare with later systems. >> >> http://www.ajwm.net/amayer/papers/B5000.html The above says the first delivery was in 1963. I believe that is the date which matters. Ideas and plans for computers are around for a long time before they come to fruition and can maybe be traced back for many years but the one date you can rely on is when a customer accepted a machine as working to its specification and paid for it. According to: http://www.chilton-computing.org.uk/acl/literature/news/1962.htm the Ferranti Atlas was working at Manchester University in 1962. I understand it had virtual memory. I wouldn't have wanted to pay for the quarter megawatt electricity bill !

15 years, 9 months

1
0
0 0

Backups in the modern world

by jonas＠otter.se

Tony Duell wrote: > The classic case of that is a demountable hard disk with headcrash > problem. It will damage any disk inserted into it, and those damaged disks > will then casue headcrashes on any other drive they're tried im. > Some indiots end up damaging every head and disk in the building.. That actually happened to a friend of mine years ago. He is/was far from an idiot, just unlucky. The first headcrash was silent, so he did not realize there had been one, put the pack in another drive, went on to copy another pack and moved that one to a third drive. By that time, the first pack had started to destroy the second drive, as witnessed by nasty sounds coming from it. But by then it was too late, the other drives started making nasty noises as well, and 60 heads and three packs had been destroyed. DECs entire stock of replacement heads was exhausted at once and they had to wait for a week while more heads were shipped in and the techs worked repairing the drives. A whole department of programmers was idle for a week. And as I said, the damage wasn't noticeable until after a little while when it was too late. /Jonas

15 years, 9 months

1
0
0 0

AlphaServer 2100

by pontus＠Update.UU.SE

On Mon, Nov 08, 2010 at 11:38:56AM +0000, Peter Coghlan wrote: > If it is not possible to save them all intact, I would be interested in some > CPU and I/O boards and possibly the backplane and memory boards if someone near > the machines is willing to extract boards and ship them to me in Ireland. I > would of course pay for shipping plus a small bonus to you and to the person > shipping them, whatever you think is appropriate. I can ask, it seems to be a nice enough guy. > As a matter of interest, do you have a ballpark price for shipping the > machines intact? A lowball estimate for _one_ machine to me in Uppsala from Lule? is 1300 SEK, but I suspect it will be closer to 2000 SEK. I'll leave conversion as an exercise for the reader. Regards, Pontus

15 years, 9 months

1
0
0 0

AlphaServer 2100

by pontus＠Update.UU.SE

Hi I'm guessing the chance is pretty slim, but if anyone in Lule? or close by wants an AlphaServer 2100 pedistal there are three available for free. They are on the way to the scrapper. I would love to pick these up but they are to far away. If anyone near Uppsala would like to share the shipping costs that would be a possibility. Regards, Pontus.

15 years, 9 months

1
0
0 0

Terak 8510/c Info?

by derschjo＠mail.msu.edu

Hi all - Just got myself a Terak 8510/c workstation, in pretty decent shape. I'm going over it, and preparing to power it up (after testing the power supply). Anyone know any details about this particular model? (And what technical differences there are between the /a and the /c?) There appears to be a good amount of information about the 8510/a, but I can't find a thing about the /c variant. The /c appears to be considerably newer (mine dates from around 1982 and is branded Calcomp on the front), seems to have replaced the single internal 8" drive with two half height 8" drives, and the keyboard and monitor are completely different. A service manual would be extremely helpful -- a few of the double-height QBus cards came loose during shipping and were banging around and I'm not sure yet what the order is supposed to be (I guess I'll have to figure out whether the backplane is serpentine or not... shouldn't be too hard) and it'd be useful to know what the power supply pinouts are so I can test the voltages. And while I'm at it -- has anyone archived any Terak floppies? There's nothing on Bitsavers and I can't find anything anywhere else. Be nice to have some software to run on this thing after I get it running again :). Thanks as always, Josh

15 years, 9 months

4
13
0 0

"Crosspost" of system rescue...

by zmerch-cctalk＠30below.com

As seen on the CoCo list (hosted by MaltedMedia): http://five.pairlist.net/pipermail/coco/2010-November/052008.html In short: 2 each Gimix 6809 multiuser systems, SS-50 based. These are quite rare critters, it would be a shame to see them go. I put a reply on that list & will echo the sentiment here: The systems are in Winnipeg, Manitoba, Canada. The owner says that shipping might be possible to the US *if* they arrange their own Customs brokerage. I'd be happy to help if I can, so even though I live in the US, I'm in a border town (I can see Canada from my bedroom window) so instead of dealing with Customs, if "the lucky rescuer" can arrange shipping to (or near, lets say 50km) Sault Ste. Marie, Ontario, Canada, I'll drive across the border, get the units, bring them into the US [1], and then reship them from the local UPS depot to their destination. [2] [1] As I'm fairly sure the units were made in the US, there *shouldn't* be any duty -- If there's any sticker or documentation that states the fact, that would be much easier to prove. [2] I reserve the right to look at the units for a few minutes -- I remember wanting one of these ever since I saw the ads in Rainbow & HotCoCo... I'll be sure to wear a bib, just in case I drool... ;-) It's much easier to deal with Customs in person, instead of "Hopefully the correct documentation (but probably not) taped to a box (but probably not) and waiting 2-3 weeks for Customs to actually find it (but probably not)." ;-) Winnipeg is about 13-14 hour drive (one way) from where I live, and my pocketbook won't stop hemorrhaging until next February (and something tells me Winnipeg in February ain't the most fun to drive...) so if this were next June, I could prolly find the time (and the $300 in gasoline/petrol) but he's indicated that his timeframe won't allow that. Just tryin' to spread the word, Roger "Merch" Merchberger

15 years, 9 months

2
2
0 0

W00T! SGI is in da house! :oD

by pu1bzz.listas＠gmail.com

Well, this is more than a child?s dream. This THE child?s dream :D Got today an Ozone with 1 proc, 768MB RAM and no hard disks :)))))))))))))))))))))))))))))))))))))))))))))))))) It is working, I already downloaded the Irix install media and found some 36GB HDs that seems to fit :D Just want to share it with you :D :D :D I?m so happy!!! It may be a toy, but I ALWAYS wanted to have a SGI computer :D I even got the original granite SGI keyboard. So bad I wasn?t able to find the matching mouse :( Now I just need to find a proper sled (at least one) for the hard disks. I think I can order one from ebay. W00T!!! I?ll play DOOM on that!!! :D :D :D Uhuuuu! :D Alexandre (happy as a child on xmas with a brand new toy :D) (photos soon, as soon as I have some free time)

15 years, 9 months

3
2
0 0

A3311A SCSI hard drive enclosure - Sleds?

by pu1bzz.listas＠gmail.com

Well, incluiding the HUGE pack of hardware I got today (and the SGI =D) I got an A3311A SCSI hard drive enclosure from HP. How hard is it to find drive sleds? It has three, a pair of 9,1GB drive and a 18GB drive. I want to find at least four drive sleds (ideally 5) so I can put my 4 36GB drives on it, and make it avaiable for the SGI, Ultra 60 or HP9000 BTW, is there such a thing like a SCSI selector, so I can direct the scsi array for one computer or another? Thanks Alexandre

15 years, 9 months

1
0
0 0

commercial scsi target mode product

by aek＠bitsavers.org

http://www.virtualscsi.com/

15 years, 9 months

3
2
0 0

CyberVision 2000

by menadeau＠comcast.net

It was sold by Montgomery Ward, and I believe it is a repackaged RCA system (uses the 1802). I have scans of literature if you want more info. ----- Original Message ----- From: "Bill Sudbrink" <wh.sudbrink at verizon.net> To: <cctalk at classiccmp.org> Sent: Saturday, November 06, 2010 6:03 PM Subject: CyberVision 2000 > Hi, > > > > Anyone know anything about this computer? Google reveals almost nothing. > > According to an email I just received, it was sold in the mid 1970's in > department > > stores around Washington, DC. Email claims before the TRS-80 and Apple > II. > > > > Thanks, > > Bill > >

15 years, 9 months

3
2
0 0

CyberVision 2000

by wh.sudbrink＠verizon.net

Hi, Anyone know anything about this computer? Google reveals almost nothing. According to an email I just received, it was sold in the mid 1970's in department stores around Washington, DC. Email claims before the TRS-80 and Apple II. Thanks, Bill

15 years, 9 months

1
0
0 0

DiscFerret: First working hardware, firmware and microcode!

by classiccmp＠philpem.me.uk

Hi guys, I have -- just this second -- got the standalone, single-board DiscFerret hardware ("0I06") to image a disc. First, the proof: Scatter plot: http://www.discferret.com/temp/dat.scatter.png Histogram: http://www.discferret.com/temp/dat.histogram.png Raw transition data, gzipped space-separated format. First column is array index, second column is the timing value: http://www.discferret.com/temp/dat.gz Rawbinary track dump, gzipped. Most significant bit of each byte is the status of the INDEX sensor (1=index detected). If (x&0x7f) = 0, then a counter carry occurred -- the next byte should have 128 added to it. Repeated counter-carries are allowed.: http://www.discferret.com/temp/dat.bin.gz MagScan analyser output for dat.bin: http://www.discferret.com/temp/dat.magscan.txt For those of you who have a copy of the sources to my Magdecode decoder engine (I know I sent it to at least one person on-list...), the Rawbinary dump should load straight into Magdecode. The space-separated data can be loaded straight into Gnuplot (which is what I used to produce the plots), and I suspect MATLAB and Octave can probably load it too. The image file was created from an old coverdisc from "PC Zone" magazine, and is completely undated on the label. The volume label is "PCZ_OCT_3" which suggests it's from October, with last-modified dates in February and August 1993. It only covers Track Zero, which (if memory serves) is the MBR, FAT and Root Directory. The disc is 720K DOS format, sampled at 40MHz. Other things to note: - The hardware works fine at 80MHz, and possibly faster than that. It should be possible to sample with enough resolution to image a 5Mbps MFM hard disc. - There are plenty of spare registers. The new PIC uses 8-bit multiplexed addressing, which gives 256 register addresses. Only 16 are in use at the moment (!) - Write support isn't enabled yet. I need to port this across from DiscRW and test it (and no doubt rewrite parts of it, as I did with the reader engine). Surprisingly, there are only a few minor issues on the 0I06 PCBs: - C6 is missing a polarity marker. This is a non-issue, as one end connects to the ground plane and the other quite obviously connects to +5V. - Some of the component pads are rather small (notably the inductors and Schottky diodes in the power supply). This makes it hard to heat both the pad and the component pin at the same time, and thus makes the parts a bit of a pig to solder. I worked around this with a hot-air gun, preheater and solder paste... later boards will have bigger pads. - The power supply chip is a QFN with pads under the chip. The only way to solder it down is to use a hot-air gun... unfortunately TI don't make this chip in a more accessible package, and the only viable alternative would have nearly doubled the size of the power supply. Despite these issues, it's perfectly possible to assemble a 0I06 and have it work perfectly, without any "green-wire" fixes. I'm impressed: usually a first-spin board needs at least one track-cut and a couple of green-wires :) Now here's where you guys come in. I really don't want to have boxes and boxes of unused boards and parts hanging around, so I need to know how many people would like to buy a DiscFerret. These would be available as: - PCB only - PCB with the power supply section assembled and tested - Fully assembled and tested PCB - Some other form -- feel free to make suggestions! I'd appreciate it if anyone interested in buying a DiscFerret could email me at philpem at philpem.me.uk, with one of the following in the subject line (start, end, on its own, uppercase, lowercase -- anything will do, my procmail rule is pretty lenient): - "I want a PCB on its own" -- DISCFERRETBARE - "I want a PCB with the PSU built and tested" -- DISCFERRETPSU - "I want the whole thing ready-built" -- DISCFERRETBUILT - "I want a DiscFerret in some other form" -- DISCFERRETOTHER Thanks to everyone who has supported the project thus far -- your thoughts, ideas, comments and criticisms have been very useful! Now to get my reflow oven working and build some prototypes... :) Thanks! -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

15 years, 9 months

19
58
0 0

TRS-80 Model II Manuals

by nathan＠nathanpralle.com

Thanks to the ever-useful JP Hindin, I've obtained a set of TRS-DOS disks and other application disks for my TRS-80 Model II system, which is the entire setup pictured here, plus a bit more: http://oldcomputers.net/pics/TRS-80-II_table.JPG It's been sitting, covered, pretty much since I obtained it, but now I can try reviving it and actually seeing what it can do. I'm going to tear into it and clean the drives and so forth, document what it has, etc. and then boot 'er up and see what we can see. I'm looking for a copy of the Technical Ref manual for it; despite finding scans of the covers and so forth online, I'm unable to actually locate one. In addition to that, if someone has a Shugart 8" Service Manual, that might come in damned handy for making sure those are up to speed as well. Many thanks, Nathan -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nathan Pralle, Computer Geek Email: nathan at nathanpralle.com Web: http://www.nathanpralle.com Blog: http://www.philosyphia.com Twitter: http://twitter.com/NathanPralle -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

15 years, 9 months

26
55
0 0

FF: 2 Maxspeed MaxStations

by g＠kurico.com

Anyone interested in two MaxSpeed MaxStations? One is a SVGA MaxStation and the other a VGA MaxStation. The SVGA version uses a PS2 kb connector, the VGA version an AT kb connector. Sorry, no power supplies. These are free, I'd prefer not to ship, but if I have no local takers then the buyer to pay shipping costs. I'm in Austin TX. These will go to Goodwill if no one is interested. I'm in the very very early stages of shedding the majority of my collection and this is just the start.

15 years, 9 months

1
0
0 0

Virtual memory

by bqt＠softjar.se

On 2010-11-01 00:02, "Chuck Guzis"<cclist at sydex.com> wrote: > On 31 Oct 2010 at 11:37, Johnny Billquist wrote: > >> > The important question here - are the programs aware of the RA >> > register, and can they change it? And can they address the full range >> > of memory addresses as perceived by the program. > No they aren't. Their memory exists from 0 to whatever the field > length is, physically and continously. If they need more, a system > request can expand their field length provided the system has > sufficient physical memory to accommodate them. There is no way > (absent perhaps a system request to get that information) for a > program to know its real physical base address. Ok. So, a program would think it addressed a memory space, which was it's own, and the addresses it used would in no way related to the actual physical memory it ended up referring to. I'd call that virtual memory. Although, having to map the whole virtual memory as one chunk to physical memory makes it a little more work, end less flexible than having pages. And it pretty much prevents you from ever being able to share memory in a reasonable way between processes. >> > Another word for swapping in and out? > But much older and specific to the architecture and not done in > pieces as a tranditional VM swap file would be. Hmm. I don't think swapping is considered to be done in pieces today either, although swapping is also a term that seems to be defined differently depending on which OS we're talking about. Unix systems can both page and swap. Swapping is throwing everything out to disk, including some kernel structures for the process. Don't happen that often nowadays... Paging is normally enough. > I'll take the coward's way out and use the dictionary here: > > "1. Existing or resulting in essence or effect though not in actual > fact, form, or name" > > So my definiton of "fooling the user into thinking he has more > physical memory than he actually has" is certainly valid. > > And the VAX sense is also true, but only if one takes along with it > the ability to over-commit memory space such that the amount of > addressable memory (i.e. the sum of all users' memory) is greater > than the physical memory present. > > A single task running on a VAX with at least as much physical memory > as addressing space would not be using the virtual memory facility-- > every bit is reflected in the presence of real memory. > > But then, we fall on marshy ground again, when we consider the old > "roll/swap" multiuser situation. I can run 8 jobs, each requiring > 65K of memory on a system with 128K physical memory, simply by > selecting when I give each a time slice and swapping/rolling them out > as needed. So is that virtual? Indeed. I remember (not so fondly) running on a PDP-11/70 back in the 80s. The machine was running RSTS/E V7, and the system allows max 63 jobs. We were at times actually 63 users running on that machine, and it only have 1.5M of memory. It was swapping a lot, and things sometimes went slow, but it worked perfectly fine. Seeing a machine today with over 60 users is not common, and I'm not sure it would feel a single bit more pleasant than the RSTS/E system I used back then... And I'd still claim that the memory used by each process was definitely virtual. And I'm willing to continue to fight for that view. Besides, for the PDP-11, that is what DEC called it. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

15 years, 9 months

6
11
0 0

PDP 11 Core Memory

by pontus＠update.uu.se

2010-11-05 23:42, Tom Gardner skrev: > > Good eyes! > > When I look more closely, it seems that the X and Y lines are under > the center sections but no cores, ergo, 16 core mats. I'd like to see > a real one to confirm. > > Tom > The reason I noticed is that I looked at a core memory board for a PDP-10 just the other day, it had one half section with missing core. I could take a picture if you like. /P

15 years, 9 months

1
0
0 0

Tek 4051 in Austin

by swtpc6800＠comcast.net

The TEK 4051 is a Graphics Terminal with BASIC in ROM, It used the Motorola 6800 microprocessor. I did a Wikipedia article on the MC6800 and illustrated it with several old advertisements including the first M6800 ad and a Tektronix 4051 ad. Here is the article http://en.wikipedia.org/wiki/Motorola_6800 And here is the TEK 4051 ad. http://commons.wikimedia.org/wiki/File:Tektronix_4051_ad_April_1976.jpg Michael Holley -----Original Message----- From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] On Behalf Of steve shumaker Sent: Friday, November 05, 2010 2:37 PM To: On-Topic and Off-Topic Posts Subject: Tek 4051 in Austin Tektronix 4051 functioning system??? Austin C/L #2043597225 looks in fair shape.? supposedly working...?? wants $150 cash and? pick up only steve

15 years, 9 months

3
2
0 0

HP9845 design article in EDN

by cclist＠sydex.com

No one seemed to notice this, but I thought I'd post it for Tony's edification. It's a story in the October 7 EDN from the "Tales from the Cube" back section and deals with solving a problem with the I/O board of the HP9845: http://bit.ly/cNwokC (it's a PDF) Enjoy, Chuck

15 years, 9 months

2
5
0 0

MFM and ESDI SCSI bridge boards (was Re: SCSI emulator)

by ethan.dicks＠gmail.com

On 11/5/10, Jules Richardson <jules.richardson99 at gmail.com> wrote: > Dave McGuire wrote: >> On 11/5/10 2:00 PM, Jules Richardson wrote: >>> It's a bit more murky than that (albeit a related issue) because a lot >>> of the bridge boards expect a vendor-specific command to tell them the >>> drive geometry of the attached drive... >> >> MFM- or ESDI-to-SCSI bridge boards (Adaptec ACB-4000, Emulex MD21 if >> memory serves) are weird to begin with... > > I think the Adaptec was one of the most sane boards out there I do have some experience with a couple of them, primarily the ACB-4000 > IIRC it stores > the drive geometry on block zero of the drive at format time, then at > power-on fetches that block back and initialises itself with the loaded geometry. That sounds somewhat familiar to me, but I wouldn't have been able to have said that's what it did without looking it up first. > I can't remember if it just hides the first block from the user, or hides the > whole track. I really can't remember that detail - been way too long, but if I had to guess, I'd guess "block" since I have a fuzzy memory about some detail about moving, say, an ST225 on and off an ACB-4000 and a different kind of controller (an XT MFM card most likely, possibly a WD WX-1 or Everex clone). > I think the board responds to Inquiry, too (although it just returns "ACB > 4000" rather than anything to do with the geometry of the attached drives) That also sounds familiar (having played at the low-level back in my early Amiga days). > I've not played with the Emulex boards - I think the only ones I have are > tape bridges rather than disk. I have a couple of the Emulex bridging boards from the Sun-3/early Sun-4 days, but I never had to set them up - they were black (beige, really ;-) boxes to me. I just stuck them on a Sun box and don't remember any special fiddling. > The Xebec and Omti boards seemed reliable, but their SCSI implementations > were > a little lacking (one of them I think had the option of a user-supplied ROM > with the expected disk geometry encoded into it, but it still wasn't "SCSI > enough" to work with a modern system) I think I tried to fiddle with an Omti board once but didn't achieve enough success to use it. One reason I tried was it was a combo hard-drive/floppy drive model. It would have been handy, but alas no. It's likely I was running into one of those "almost-SCSI" problems and lacked sufficient documentation. Since I moved from PETs and C-64s and small DEC machines first to Amigas and Macs, then much later to PCs, I was very happy when embedded SCSI drives displaced all the Adaptec and Emulex and Xebec and Omti boards - much easier to set up and move from environment to environment. -ethan

15 years, 9 months

3
2
0 0

Kaypro "Profile" Magazines free+postage from 95006

by shumaker＠att.net

available for free + postage from 95006: several partial years of the KayPro focus magazine "Profiles": Dec/Jan 85 ?Dec 85 (full year) Jan-Mar 86; Jul 86 Jun ?Jul 87; Sep ? Dec 87 Jan ? May 88 Note that these issues are all available as scanned docs (or will be shortly) on Gene Buckle's site at www.retroarchive.org. But if you gotta have an original.... I figured I'd offer them here before they get recycled. mags are in good shape. steve

15 years, 9 months

2
1
0 0

Bill's PDP-11/34A

by bqt＠softjar.se

On 2010-11-03 18:00, Ethan Dicks<ethan.dicks at gmail.com> wrote: > On 11/3/10, B Degnan<billdeg at degnanco.com> wrote: >> > Here are pictures from the system as I first got it, if it helps with >> > the card order/comparison purposes. Note that some cards are not >> > installed in the backplane. >> > http://vintagecomputer.net/digital/pdp11-34a/before/ > Do you have packs for your RL01 drives? Hopefully the packs were > removed and the heads locked for transport. Good point. There is a transport lock for RL drivers, that should be in place when transported, and which should be remembered to be moved out of the way when used. > An 11/34 w/RL01 is a nice little RT-11 system, though it'd be a bit > cramped for 2.9BSD (both in terms of disk and RAM). You could > probably also run an older version of RSX-11/M on it too. I think we > ran something around RSX-11/M 4.0 or 4.1 on ours in the mid-1980s. You can always get more disk. Easiest would just be an upgrade to RL02 drives... Also, current RSX-11M would also be happy on that machine, assuming he has the full 256K of memory. Once more possibly disk space being an issue, though. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

15 years, 9 months

2
1
0 0

PDP-11 firsts?

by bqt＠softjar.se

On 2010-11-01 00:02, ard at p850ug1.demon.co.uk (Tony Duell) wrote: >> > On 2010-10-30 01:12,ard at p850ug1.demon.co.uk (Tony Duell) wrote: >> > >>> > > >>>>> > >> > I have not seen anyone comment any of the other things I listed as >>>>> > >> > possible firsts on the PDP-11. >>>>> > >> > Can anyone come up with an earlier machine that used condition codes? >>>>> > >> > How about general registers with addressing modes, which is totally >>>>> > >> > orthogonal? How about having the PC as a general register? >>> > > The Philips P800 series has the PC as a general register (register 0). >> > >> > Could you use it like any other register? > There were some restrictions. I don't think you could shift it (at least > ont on the P850). But for many instructions it was just another register. Cool. So you could add to it, index by it, and so on? >>> > > There are 16 registers, some instructions can only use the first 8, others >>> > > can use all 16. Addressing modes (simpler than the PDP11, I admit) are >>> > > pretty much orthogonal. >> > >> > Sounds like the registers were atleast not as orthogonally used as on a >> > PDP-11. If an instruction could take a register, it could take any >> > register. And all addressing modes are valid (well, almost) anywhere. > I think all P800 instructions that had addressing modes could use any > addressing mode. Any instruction with 4-bit register fields could use any > register. Any instruction with a 3 bit register field could use any of > the first 8 registers. And IIRC, like the PDP11, the addressing modes > commonly known as 'immediate' and 'absolute' were a couple of the other > addressing modes with the register specified as 0 (=PC, of course). > > I guess the P800 wasn't totally ortogonal but it was a lot more > orthogonal than many other machines. Indeed sounds nice. When did the machine appear? >>> > > What do you mean by condition codes here? >> > >> > The four low bits of PSW. > Err... I don;t think that's helpful. Quite a lot of machines with a > status register have a 'low 4 bits' of it:-). But that doens't make them > condition codes. Similarly uf you hapopen to implement the same > functionality using other bits of a status registers, doesn't that make > them condition codes? > > What I was asking was what fucntionality do you require of these > condtiion codes other than there being conditional jumps on carry, zero, etc? Sorry. I was just being lazy, and trying to explain condition codes by referring to what they are on the PDP-11. To try and be more specific then: condition codes are bits that are set/reset as a result of operations performed by the processed, and upon which you can the make conditional branches/jumps on. As opposed to, for example, a PDP-10, where you instead encoded the condition within the instruction, along with a register to test upon. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

15 years, 9 months

2
1
0 0

PDP 11 Core Memory - H214 Memory Stack

by thomas.gardner＠sbcglobal.net

There are several pictures of an 8 KiWord H214 Memory Stack posted on the Internet, for example, see http://www.conservatique.com/_/rsrc/1251146207239/pdp/pdp-1105/H214-c... <http://www.google.com/url?sa=D&q=http://www.conservatique.com/_/rsrc/125114 6207239/pdp/pdp-1105/H214-core-plane%3Fheight%3D167%26width%3D200&usg=AFQjCN GgCgWQk-XDZ2griejhV44yO10CAQ> At least one DEC manual describes the H214 as having "16 memory mats arranged in a planar pattern" but the photo referenced above (and many others) show 20 memory mats arranged in a two x ten planar pattern. Two by ten is a very strange array for a machine that has a 16 bit word or 18 bits in one with the byte parity option. Can anyone explain what is going on? Tom Note this is also posted to alt.sys.pdp11 <http://groups.google.com/group/alt.sys.pdp11>

15 years, 9 months

2
1
0 0

68K

by bqt＠softjar.se

On 2010-11-01 18:00, Ethan Dicks<ethan.dicks at gmail.com> wrote: > On Sat, Oct 30, 2010 at 6:51 AM, Johnny Billquist<bqt at softjar.se> wrote: >> > On 2010-10-30 01:12, Ethan Dicks<ethan.dicks at gmail.com> wrote: >>> >> I know it works well enough in early Sun workstations and the AT&T >>> >> Unix PC (3B1/7300), but I have no knowledge of any required >>> >> workarounds due to possible bugs. >> > >> > Yes, the 68010 worked fine with demand paging. The 68000 did not. >> > Neither of them implemented instructions restarts, though. As noted below, >> > the 68010 did instuction suspension instead. > Yes. I was previously unaware of the distinction but did know what > the 68000 could not do that the 68010 could. We were at the same level, then. :-) >> > The "interesting" workarounds that I've hear of are actually 68000-related... >> > Using their own designed MMU (there were none from Motorola for the 68000), > What about the 68451? (we had one in a prototype product design in > 1984/1985 that never made it to market) > > It wasn't terribly popular, but it did exist. Tried to look it up on the net, and I'm unsure if it really was usable on the 68K. It would appear that it did hit the market, and if you had a 68010 in combination with this chip, you could implement virtual memory, since you could recover from page faults. However, there were also third party MMUs competing with the Motorola chip, which might explain why it was rather uncommon. Performance wise, the 68010 in combination with the 68451 appear to not have been that impressive. >> > and a second CPU, Apollo made the primary CPU stall on a page fault, and the >> > secondady CPU wake up. The secondary CPU could then do a page in... > That sounds like the design of the Perkin-Elmer workstation I have - > two 68000s, one for running the OS, one for paging. I wouldn't be surprised to learn that SUN did something similar as well... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

15 years, 9 months

2
1
0 0

Moving Home - repeat

by williams.dan＠gmail.com

Hi, I still have : An Octane Sun Blade 2000 Dell Itanium blade (Heavy) 2 x Dual machine blade sparc machines I hate to do this but if they are not claimed by Monday they will have to be thrown out. I have also found a processor card still in it it's box for a Vax 4000/500 if anyone is interested. Dan

15 years, 9 months

3
3
0 0

Early Fairchild Sentry scrapped, early TTL IC's worth preserving ?

by jdr_use＠bluewin.ch

The remains ( mostly just the PCB's ) from an early Fairchild Sentry test system were junked today. The PCB's are brimming with early ( 1974 datacodes ) Fairchild TTL ic's. ( (9xxx and 93xx ) Also ECL of course, but I don't do that ! Any worth looking for, in particular w.r.t. to keeping old PDP's running ? Jos Dreesen

15 years, 9 months

5
5
0 0

SparcStation Voyager framebuffer problem

by IanK＠vulcan.com

I posted not too long ago looking for a framebuffer driver that seemed to be missing from the Solaris distributions I have for my Voyager. Well, I finally opened up the machine and found something quite unexpected. I had assumed (as had others, according to statements) that the color and monochrome components (screen and framebuffer) would be physically incompatible, so it would be impossible to mix and match. *Wrong!* In fact, I found I have a color framebuffer, which was talking to the monochrome screen. What's really strange is that OpenBoot seems to have created a new name - bwthree - to describe the framebuffer! I don't suppose anyone has a monochrome framebuffer with which you might be willing to part company? Or perhaps a color screen? -- Ian UNIX is user friendly. It's just selective about who its friends are. Ian S. King, Sr. Vintage Systems Engineer Vulcan, Inc. http://www.livingcomputermuseum.org

15 years, 9 months

8
20
0 0

Fwd: Ersatz-11 V6.0 PDP-11 emulator

by pat＠computer-refuge.org

Finally, you can run a PDP-11 on OS/2, even if you can't run OS/2 on your PDP-11. ---------- Forwarded Message ---------- Subject: Ersatz-11 V6.0 PDP-11 emulator Date: Wednesday 03 November 2010 From: John Wilson <wilson at dbit.com> To: Info-PDP11 at dbit.com ... - OS/2 version. "Finally!" I hear you say. OK I know there isn't much overlap between the OS/2 crowd and PDP-11 folks, or between the OS/2 crowd and anyone, really -- but *I* like it better than Windows, so there. YOU don't have to use it! OK OK, just let me breathe. -- Purdue University Research Computing --- http://www.rcac.purdue.edu/ The Computer Refuge --- http://computer-refuge.org

15 years, 9 months

2
1
0 0

Information about Tektronix 4107A/4109A graphic terminals

by dm561＠torfree.net

Date: Wed, 3 Nov 2010 13:52:40 -0400 From: David Ryskalczyk <d235j.1 at gmail.com> Subject: Re: Information about Tektronix 4107A/4109A graphic terminals > A little OT but speaking of vintage Tek: I have a bunch of their Service > Scope 'magazines' from the late 60's; can I assume that these exist > elsewhere and I can dispose of them if and when? > > mike > Have you checked BAMA? http://bama.edebris.com/manuals/ I'd offer to scan them (I have an Epson GT-15000 scanner with ADF) but an currently overloaded with DEC documentation to do. --Dave ++++++++++++++++++++++++++++++++++++ Didn't see anything there, but it looks like they're available on CD, so no sweat. Going to read 'em first anyway before I throw 'em out; some still-relevant interesting tips in those old magazines. mike

15 years, 9 months

1
0
0 0

CDC STAR was: Happy Birthday VAX 11/780 (influence of)

by cclist＠sydex.com

On 4 Nov 2010 at 9:39, Jerome H. Fine wrote: > TI ASC??? TI's Advanced Scientific Computer. The only reason I was aware of the ASC (and Burroughs' BSC) was because of some proprosal-writing I did for ECMWF (European Centre for Medium-Range Weather Forecasting) proposal. We didn't get the contract, but part of your "homework" was to become familiar with competitors' products. >From my often-faulty memory, the ASC was roughly based on the IBM S/360 instruction architecture with a rather arcane (at least it seemed so to me) vector box. 32 bit single-precison/64 bit double- precision with the S/360 style (8+24, normalized to 4 bits) floating point representation. I just did a check and there's some stuff on Bitsavers on it. However, I don't see anything on the BSC there. When we talk today about selling thousands and millions of systems, it was a very different world where vast amounts of money and manpower were put into the hope of selling 10 systems worldwide. One aspect of these supercomputers that's often overlooked is the amount of R&D that goes into peripherals to keep these things fed. TI had a special horizontal-spindle disk drive; STAR had some work done on a super-speed drum and a very wide tape-used-as-movable drum called SCROLL. I don't think that CDC's EBAM was ever considered for STAR (maybe early on), though I do recall seeing a rack of EBAM units sitting in the hall at ADL. By then, Jim Thornton had moved on to other things and was trenching around the parking lot at Arden Hills, burying coax for his 50Mbps network experiments. --Chuck

15 years, 9 months

2
1
0 0

Happy Birthday VAX 11/780 (influence of)

by bqt＠softjar.se

On 2010-10-29 19:00, "Chuck Guzis"<cclist at sydex.com> wrote: > On 29 Oct 2010 at 0:11, Johnny Billquist wrote: > >> Next question: Does the VAX not have virtual memory any more now that >> I've pointed this out? Or do you need to redefine virtual memory in >> yet a new and strange way to exclude the PDP-11... :-D > > I think that using memory address spaces to qualify the "virtualness" > of memory is following the wrong animal. I think that virtual address space is intimately connected to virtual memory, and you cannot have one without the other. If your program vrites data to address 0, and reads it back, and get the same data back, and another program on the same machine, at roughly the same time, write to address 0, and reads the same data back, and that data is different than the first programs data, then I'd say you have virtual memory. > I would define "virtual memory" as the ability to fool a program into > thinking that it has more physical memory than is actually present. > So, can a PDP-11 with 16K of memory appear to a program as if there > were 32K present? Certainly. If we just disregard that the code needed to implement this thing might need more memory than 8K. The program that we intend to fool must have atleast 8K of physical memory, to which we can read in and out pages. With 16K that would leave just 8K for out demand paging software... Well, actually, this is a bit too simplified. An instruction can potentially refer to 4 pages, so we would need to be able to have four pages to be able to fully fool a program. That would mean minimum 32K of physical memory to use for the user program. And then some for your kernel. But you'd probably be able to come in under 56K, while fooling the program that is has 64K. With less than four pages, you could get into a situation where mapping in one page means you have to map out another, which the instruction refers to, and when you restart the program you'll just get another page fault, ad infinitum... :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

15 years, 9 months

6
9
0 0

DEC H9504 'double hi-boy' cabinet parts

by adam＠nitrate.plus.com

Good morning / afternoon / evening people. For long enough now my PDP 11/70 (decdatasystem 570) has sat around without the side panels ('skins') or the lower front cover (the long, usually blue panel with the air vents). Can anybody assist with clothing this magnificent beast? I ask now because I _had_ a 11/60 cabinet for this purpose reserved with a dealer, but they scrapped it a few weeks ago (just when I wanted to collect it). I'm in the UK by the way before people read too far. In the north actually, but am very willing to travel for the right bits. Cash waiting, if thats what you want. According to the 11/60 document MP00166 (the 11/60 in this case being housed in the same H9504 high-boy corporate cabinet), the part numbers are as follows: Side skins: H9504-CA Front cover: H9504-Rx (x denotes the colour / logo config but I'm not bothered... it can be resprayed) If somebody had the whole cabinet, I have a trailer!! The side panels can also be found on many expansion cabinets / tape systems (for example they are used on my TS11) and, by the looks of it, early VAX. I'd be very appreciative if anybody can help me out. Condition is really unimportant as I have a paint sprayshop handy. Thanks in advance! ..Adam..

15 years, 9 months

1
0
0 0

TTL HEX LED driver chip

by chd＠chdickman.com

Was there ever such a thing as a 74x00 series LED driver that did proper hex decoding and not simply BCD? I can't seem to find that there was. The topic of why split octal was used on some early micro-computers came up on a list. After doing a search for a TTL LED driver that does hex, the answer is probably that there were no single chip option for hex displays. Split octal was just easier. This kind of joins in with the TIL311 discussion. It was a TTL compatible hex display, but expensive at the time. -chuck

15 years, 9 months

20
82
0 0

Watts Humphrey

by evan＠snarc.net

Watts Humphrey, known as the "father of software quality testing" died a few days ago. He was 83. Watts was a keynote speaker at VCF East 5.0 (two years ago.) He worked on the MOBIDIC ("Mobile Digital Computer") and on the Fieldata spec (which became ASCII), and which both happened at the Army base that's now our museum. Favorite story that I enjoy telling: Watts explained how, when MOBIDIC was finished and mounted in its 30-foot truck (late 1950s), the Army insisted on testing it like any other military vehicle. So they drove the computer-truck to the Aberdeen Proving Ground. On two test laps, the computer itself came through with flying colors both times. Also on both laps, the truck broke down! Here are some obituaries: Press release -- http://tinyurl.com/2fwdu27 Carnegie Mellon -- http://www.sei.cmu.edu/watts/ SD Times -- http://tinyurl.com/243shql* *

15 years, 9 months

4
7
0 0

Information about Tektronix 4107A/4109A graphic terminals

by d235j.1＠gmail.com

Anyone out there have one of these? I have one of each, but one is broken and has an incomplete set of ROMs (which appear to be one of the early versions -- maybe 1.0!). I do have a complete set of version 8.2 ROMs, dated 1985. Someone posted photos of a 4107A a while ago at http://picasaweb.google.com/glen.slick/Tektronix4107A#5300179266366767714 . The 4109A we have is fully intact, but the 4107A has front panel damage. Also, we're not sure whether or not we have keyboards and mice. Any information, including owner's and service manuals, would be greatly appreciated. --Dave

15 years, 9 months

7
8
0 0

Bill's PDP-11/34A (was Re: PDP-11/34A bring up (question about front panel))

by ethan.dicks＠gmail.com

On 11/3/10, B Degnan <billdeg at degnanco.com> wrote: > I don't want to hijack this thread except to say that I too just got an > 11/34 last week. I still need to clean it and learn more about what it > was set to do, but I have a quick question about the front panel. My > system has a flat front panel without the white cover cut out resembling > a mirror image of the US State of Delaware on it's side. My system has > a black front panel with a white rectangular frame around it instead. > What is the origin of this variation? I have never seen that mounting frame for the front panel, but perhaps it's related to your "DEC DataSystem" cover panel. Here's a photo I found googling around for "DEC Datasystem" http://www.compuseum.at/portal/Computers/PDP1134/tabid/93/language/en-US/De… > Here are pictures from the system as I first got it, if it helps with > the card order/comparison purposes. Note that some cards are not > installed in the backplane. > http://vintagecomputer.net/digital/pdp11-34a/before/ Do you have packs for your RL01 drives? Hopefully the packs were removed and the heads locked for transport. An 11/34 w/RL01 is a nice little RT-11 system, though it'd be a bit cramped for 2.9BSD (both in terms of disk and RAM). You could probably also run an older version of RSX-11/M on it too. I think we ran something around RSX-11/M 4.0 or 4.1 on ours in the mid-1980s. -ethan

15 years, 9 months

5
11
0 0

PDP-11/34A bring up (question about front panel)

by billdeg＠degnanco.com

> > >> > >> > I am the new keeper of the PDP-11/34A that Jack Rubin rescued a while >> > ago and wrote about here, >> > >> > http://decpicted.blogspot.com/2010/01/pdp-1134a-data-systems-design-dsd-880… >> > >> > I took it on a road trip from Chicago back to St. Paul after VCFMW >> > in September. >> > >> > I've been doing a lot of cleanup on it and finally got to the point >> > where I could power it on (just the CPU box) this weekend. >> > >> > I think now I need to learn about Grant Continuity ;-) >> > > I look forward to reading more about this. I don't want to hijack this thread except to say that I too just got an 11/34 last week. I still need to clean it and learn more about what it was set to do, but I have a quick question about the front panel. My system has a flat front panel without the white cover cut out resembling a mirror image of the US State of Delaware on it's side. My system has a black front panel with a white rectangular frame around it instead. What is the origin of this variation? Here are pictures from the system as I first got it, if it helps with the card order/comparison purposes. Note that some cards are not installed in the backplane. http://vintagecomputer.net/digital/pdp11-34a/before/ Bill

15 years, 9 months

3
2
0 0

Information about Tektronix 4107A/4109A graphic terminals

by dm561＠torfree.net

Date: Wed, 3 Nov 2010 00:31:49 -0500 From: Randy Dawson <rdawson16 at hotmail.com> Subject: RE: Information about Tektronix 4107A/4109A graphic terminals Hi David, Eiter I or Ed may be able to help - I know I have a few 4000 series manuals. Ed runs VintageTek, a Tektronix museum here in Beaverton: vintagetek.org We are meeting Thursday for the bi-weekly run at the Tek Surplus store, I ask to see what he has available. Randy +++++++++++++++++++++++++++++++++++++++++++++++ A little OT but speaking of vintage Tek: I have a bunch of their Service Scope 'magazines' from the late 60's; can I assume that these exist elsewhere and I can dispose of them if and when? mike

15 years, 9 months

2
1
0 0

Bill's PDP-11/34A

by billdeg＠degnanco.com

> > I have never seen that mounting frame for the front panel, but perhaps > > it's related to your "DEC DataSystem" cover panel. > > I've seen that sort of frame a couple of times; they were used in > (possibly among other things) embedded applications. It's been a long > time but I think I saw them in big GenRad board testers. > > > Here's a photo I found googling around for "DEC Datasystem" > > > > http://www.compuseum.at/portal/Computers/PDP1134/tabid/93/language/en-US/Def ault.aspx > > Hey, that looks just like the rack my 11/70 is in. > That could explain the original purpose of the 11/34 in my possession, the rack that the system came in has a DEC DataSystem panel: http://vintagecomputer.net/digital/pdp11-34a/before/2010-10-27_20-42-43_160. jpg Bill

15 years, 9 months

1
0
0 0

10 Hole Disk Punch

by robin＠hx-20.com

> So they're 10 sector 5.25" floppies. Vector Graphic maybe? >To the best of my recollection, the VGs were 16RH, not 10. To which end >I asked Dwight if a 16 hole model might be feasible. >De The two Heathkit / Zenith HZ89s that I have both have hard-sectored 5.25? floppy drives. I successfully made some new disks up when I got them (circa 1991) by making a paper template from an original hard-sectored disk and punched holes in soft-sectored disks using a pencil. It worked but the disks are noisy due to ?burrs? around the holes catching on the sleeve inside the envelope. Robin

15 years, 9 months

1
0
0 0

Radio Shack Science Fair manuals

by pkamphues＠gmail.com

Wondering if you still have a manual for the science fair 200 in one kit. I have an old kit in great shape but no manual and I'd like to have it for the kids. Thanks Pete. Pkamphues at gmail.com

15 years, 9 months

1
0
0 0

Nuclear Data ND 6600

by legalize＠xmission.com

The Nuclear Data ND 6600 was some sort of laboratory PDP-11 setup. I have a terminal from such a system (very nice green keyboard). I'll upload some pics this week. However, while I was packing up the stuff I bought at the vendor's store, I saw that he had the rest of the system and not just the one terminal. Looks like a couple other terminals, some characteristically PDP-11 enclosure boxes (2x floppies, some other stuff, power enclosure). It looks like this stuff was meant to be rack mounted, except for the terminals, because there's no typical DEC enclosure like I would expect. Googling doesn't turn up anything useful except the usual firewalled citations from IEEE and ACM journals containing product announcements. Does anyone know more about these systems? From the descriptions that leak through google, it appears that it might have had some graphics capability and that interests me quite a bit. I couldn't look at the system close up because it was on a huge pile of stuff and I didn't have time to dig it out. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

15 years, 9 months

5
5
0 0

Amstrad 3in drive spares

by classiccmp＠philpem.me.uk

Hi guys, I've just acquired a pair of 3-inch Amstrad floppy drives, apparently >from a CPC (they're fitted with black faceplates). One is an EME-231, the other is apparently an EME-156 (someone's blanked out the model number with a Sharpie). Problem is, the 156 has a snapped drive belt, and the 231 belt feels REALLY loose. (They also look like they've been stored in a dusty box for a few years, but that's a problem for later...) Does anyone have a couple of spare belts for these, or a lead on a source who'll sell me a couple of them without wanting to charge me some silly amount of postage on top? Thanks, -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

15 years, 9 months

12
19
0 0

surplus source for MRA connectors?

by dm561＠torfree.net

Date: Tue, 02 Nov 2010 15:53:01 -0700 From: Al Kossow <aek at bitsavers.org> Subject: Re: surplus source for MRA connectors? On 11/2/10 3:14 PM, MikeS wrote: > I'll see what there is. > Thanks! The connectors were quite common at one point. I was frustrated when I ran around to the usual Bay Area surplus places and found almost no Winchester connectors or pins anywhere. There are almost none on eBay, either. Looking for a connector there is a real nightmare there, trying to guess how someone would list them. ++++++++++++++++++++++++++++++++++++++ Sorry, Al; found some Winchesters and some Continentals that look compatible, but only 34, 50 and 75 contact versions, no 42s. Hope Will has some for ya. mike

15 years, 9 months

1
0
0 0

surplus source for MRA connectors?

by shoppa＠trailing-edge.com

> Looking for a connector there is a real > nightmare there, trying to guess how someone would list them. The very broad term for this style is "rack and panel". 50-way is an industry standard (at least in my industry! We have them by the tens of thousands) but I don't know about any multi-sourced 42-way. Tim.

15 years, 9 months

1
0
0 0

Large geometry MFM drive testing

by snhirsch＠gmail.com

All, I'm trying to evaluate a pile of large MFM hard drives for functionality. I'm attaching them to a WD-1006V-MM2 controller and running Sprinrite 4 under DOS 6.0 (using a 486 EISA motherboard). This works fine for drives with < 1024 cylinders, but I cannot seem to remember (or figure out) how to surface-test drives with more cylinders (e.g. Priam V185 with 1166). How do folks on the list test these beasts? I've seen SCSI controllers and ESDI controllers with CHS translation, but that feature does not seem to be available on the MFM adapters. Steve --

15 years, 9 months

2
7
0 0

little PC104 board for projects

by aek＠bitsavers.org

I'm fond of using little PC104 boards for projects. Here's one of the cheapest I've seen (clearance at $110). Doesn't have VGA, which I don't use anyway. http://buy.advantech.com/CPU-Modules/CPU-Modules/model-PCM-3343L-256A1E.htm

15 years, 9 months

1
0
0 0

surplus source for MRA connectors?

by dm561＠torfree.net

Date: Tue, 02 Nov 2010 10:27:45 -0700 From: Al Kossow <aek at bitsavers.org> Subject: surplus source for MRA connectors? In particular, the MRA42P solder cup 42 pin "winchester" plug for Diablo 31 disk drives. parts scalpers are asking $75 ea, and have made web searching useless looks like on-line surplus store catalogs have all but disappeared ++++++++++++++++++++++++++++++++++++++++++++++ Well, by one of those serendipitous coincidences only yesterday I was looking at a rat's nest of cables including some with MRA connectors (mostly only one gender of course, so not much use), wondering whether it was worth cutting off the connectors and trying to get a few bucks for the copper or whether to just toss it all into a dumpster somewhere. I'll see what there is. mike

15 years, 9 months

2
1
0 0

TTL HEX LED driver chip

by dm561＠torfree.net

Date: Tue, 02 Nov 2010 11:06:31 -0700 From: "Chuck Guzis" <cclist at sydex.com> Subject: Re: TTL HEX LED driver chip On 2 Nov 2010 at 13:33, MikeS wrote: > There's that ubiquitous string instrument again (I guess if it were a > girl's name it'd be in caps?), mysteriously in reference to a > hexadecimal display this time... I've long wondered if the Germans exclaim "Bratsche!" --Chuck (not giving in to repeating a very long list of viola jokes) ++++++++++++++++++++++++++++++++++++++ Well, it'd have to be "Bretscha", wouldn't it? And for those who wonder why it's called a "Bratsche" or just need a viola joke fix after that: http://www.mit.edu/~jcb/viola-jokes.html m

15 years, 9 months

1
0
0 0

TTL HEX LED driver chip

by dm561＠torfree.net

Date: Tue, 2 Nov 2010 14:22:48 -0400 From: Dan Roganti <ragooman at gmail.com> Subject: Re: TTL HEX LED driver chip On Tue, Nov 2, 2010 at 2:06 PM, Chuck Guzis <cclist at sydex.com> wrote: > On 2 Nov 2010 at 13:33, MikeS wrote: > >> There's that ubiquitous string instrument again (I guess if it were a >> girl's name it'd be in caps?), mysteriously in reference to a >> hexadecimal display this time... > > I've long wondered if the Germans exclaim "Bratsche!" > > --Chuck > (not giving in to repeating a very long list of viola jokes) > isn't this attributed to deep seeded oppression of diodes versus just a typo ;) ++++++++++++++++++++++++++++++++++++++++++++++++ Aw come on now, that's not fair! I think I can speak for Chuck as well when I say unequivocally that although we may have inadvertently stepped on and crushed (or exceeded the PIV of) one or two we have never oppressed a single diode in our entire lives, whether deep seededly (sic) or not; as a matter of fact I love the little buggers, silicon or germanium, Schottky or not, high power or low power and all powers in between, equally and without prejudice, and have assembled many little teams of them in matrices on the outputs of a demux chip to solve problems like this in a simple, straightforward, low power (and cheap) way. mike

15 years, 9 months

1
0
0 0

surplus source for MRA connectors?

by aek＠bitsavers.org

In particular, the MRA42P solder cup 42 pin "winchester" plug for Diablo 31 disk drives. parts scalpers are asking $75 ea, and have made web searching useless looks like on-line surplus store catalogs have all but disappeared

15 years, 9 months

5
5
0 0

Amstrad 3in drive spares

by dm561＠torfree.net

Date: Tue, 02 Nov 2010 06:36:07 -0700 From: "Chuck Guzis" <cclist at sydex.com> Subject: Re: Amstrad 3in drive spares >A word of caution here--observe that the 4-pin power connector looks exactly like a standard 3.5" conector, but the +12 and +5 leads are interchanged. If you try to use a power connector wired for a 3.5" drive, you'll make magic smoke. +++++++++++++++++++++++++++++ WHOA! Now that's a pretty harsh way of making sure folks only use your proprietary drive...

15 years, 9 months

1
0
0 0

TTL HEX LED driver chip

by dm561＠torfree.net

Date: Tue, 2 Nov 2010 09:03:41 -0400 From: Dan Roganti <ragooman at gmail.com> Subject: Re: TTL HEX LED driver chip <snip> >But I like the last solution even more, 2 chips, 74247, 74138, transistor >inverter, a few diodes, viola ! ++++++++++++++++++++++++++++++++++++++++++++ There's that ubiquitous string instrument again (I guess if it were a girl's name it'd be in caps?), mysteriously in reference to a hexadecimal display this time... ;-)

15 years, 9 months

3
2
0 0

ISO Century Data AMS 315 service manual

by aek＠bitsavers.org

Haven't tried looking for this in a while, maybe one has shown up somewhere AMS 315 14" 300mb winchester service manual (circa 1982) preferably with Trident interface (SMD was more common) I'll be putting up the product manual and brochure for it on bitsavers today

15 years, 9 months

1
0
0 0

Repairing core memories....

by djg＠quoth.pdp8online.com

>So I have these 2 PDP-8/L core stacks I am trying to recover: > Is there any realistic way of getting one fully functional stack out of > these ? > I assume the 8/L core stack is the same as the 8/I. Its made up of 3 core plane boards and the 2 diode boards. If you can figure out if one of the planes in the really bad stack seems good you could swap it with the other stack. >One would be perfect, if bit 3 @ adr 0 would be alive... > If you haven't you may want to check memory current and strobe timing to see if its totally dead or can be adjusted back to working.

15 years, 9 months

3
2
0 0

Commodore 64 on Craigslist.

by christian_liendo＠yahoo.com

http://8bitaficionado.com/2010/11/02/commodore-64-err-hmm-ugh-amusing-craig… This is the original advertisement http://longisland.craigslist.org/sys/2028894979.html I figured someone will enjoy this. BTW: Please don't call harass the guy who owns this.

15 years, 9 months

2
1
0 0

Happy Birthday VAX 11/780 (influence of)

by bqt＠softjar.se

On 2010-10-27 06:20, William Donzelli<wdonzelli at gmail.com> wrote: >> > 1.> The PDP-11 was in architectural ways more important than the VAX, if >> > ?> nothing else than just because the VAX was basically just extending the >> > ?> PDP-11. > Just to throw another question into the fire: > > Just how important was the PDP-11 or VAX-11/780 hardware architecture > in the grand scheme of things? Did either machine really bring > anything new to the table? I honestly don't know. The PDP-11 have been attributed with the common I/O and memory bus (Unibus), with memory mapped I/O as well as the concept of condition codes. Also the general registers with a nice set of addressing modes to use on them. And we should probably not forget having the PC as just a general register (although few, if any, picked that one up). So the PDP-11 can be used as a accumulator-based machine, a memory-memory based machine, or a stack based machine. It's possible to implement all concepts found in architectures at that time easily on the PDP-11. The basic PDP-11 architecture was deigned so that if an instruction took an argument, any kind of argument was equally valid. But as usual, the question is: was really the PDP-11 first with these things, or can you find earlier examples? Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

15 years, 9 months

8
8
0 0

Repairing core memories....

by dm561＠torfree.net

Date: Sun, 31 Oct 2010 14:22:35 -0400 (EDT) From: "O. Sharp" <ohh at panix.com> Subject: Re: Repairing core memories.... On Sun, 31 Oct 2010, Jos Dreesen wrote: > So I have these 2 PDP-8/L core stacks I am trying to recover: > > One would be perfect, if bit 3 @ adr 0 would be alive... > Although this is 99.99% OK, it is of course not good enough. <snip> I suspect I'm not the only one on the list who: -thinks opening up a core-stack and repairing it is theoretically possible; -also thinks it would be a hell of a daunting project; -is somewhat amazed at the dexterity and patience of the people who originally hand-wired them at manufacture; and -thinks pulling off a repair of a core-plane by rewiring it by hand would give significant bragging rights. :) -O.- +++++++++++++++++++++++++++ Agreed ;-) But if anybody does want to, I've got a small (220x16) MDS (Fabri-Tek) core plane with an already damaged section, cut-off edge connectors etc. to practice on; for even more fun I could even throw in a few of two different sizes of raw cores... mike

15 years, 9 months

2
1
0 0

CCC: New Docs Uploaded

by silent700＠gmail.com

Trying to get back into the scanning groove - got shelves of manuals that need to become bits instead of paper. These two aren't going to burn up the Internets but they're now merged with the digital infinite: Land Innovation Site Computation and Design for HP 86/87: http://chiclassiccomp.org/docs/index.php?dir=%2Fcomputing/LandInnovation An unknown, unsourced disassembler dump of the SOL20 boot ROM: http://chiclassiccomp.org/docs/index.php?dir=%2Fcomputing/ProcessorTechnolo… Neither of these were original documents and were in somewhat bad shape, so the originals are out the door. Other stuff I'm scanning I will keep as relics, but most will be offered up (most for free) after they're scanned. -j -- silent700.blogspot.com Retrocomputing and collecting in the Chicago area: http://chiclassiccomp.org

15 years, 9 months

1
0
0 0

Some IBM Core Memory Artifact Help if possible

by thomas.gardner＠sbcglobal.net

Hi Can anyone provide: 1) The dimensions of the memory plane from the Type 738 Memory used in the IBM 704 and other computers of its generation. There is an undimensioned photo in Pugh's "Memories That Shaped An Industry" C 1984 (p.158) that makes a 4 KiB plane look to be about 14 in by 7 in. A high quality photo would be appreciated. I can send anyone a scan if they care. 2) A photo and dimensions of the M4I memory plane (that's M4eye not M4one) that was used in the System 360 M65 and M70. The Computer History Museum has an artifact identified as a, Magnetic Core Plane, IBM /360 Model 65, http://www.computerhistory.org/collections/accession/102627815, but it looks too small and too crude to be for those machines. I could be wrong so I would appreciate someone who could verify the artifact or alternatively the correct photo and dimensions. Pugh is unclear but he does imply a much larger frame. This is for a web exhibit I am preparing for the Computer History Museum Any help would be appreciated. Thanks Tom

15 years, 9 months

1
0
0 0

Wanted : Monitor Capable of TTL RGB

by williams.dan＠gmail.com

Hi, I am on the lookout for a monitor something similar to a Phillips cm3388 does anyone near London have one they would like to sell or trade, or know of anywhere I could get one. Thanks Dan

15 years, 9 months

6
10
0 0

Repairing core memories....

by jdr_use＠bluewin.ch

So I have these 2 PDP-8/L core stacks I am trying to recover: One would be perfect, if bit 3 @ adr 0 would be alive... Although this is 99.99% OK, it is of course not good enough. The other stack seems to be a total loss : 2 sense wires are open circuit, more than 20 select diodes shorted. Of course the further quality of the cores is unknown. Is there any realistic way of getting one fully functional stack out of these ? Removing a single core from the really bad stack to the almost OK stack would seems almost feasible to me, since address 0 is bound to be on a edge of a core mat. Any ideas / suggestions ? Jos

15 years, 9 months

10
12
0 0

classiccmp web site mirrors?

by tingox＠gmail.com

Hello, As I still can't reach the classiccmp web site - are there mirrors anywhere? (I have the same problem with bitsavers.org, luckily most mirrors works) HAND -- Regards, Torfinn Ingolfsen

15 years, 10 months

1
0
0 0

68K (was: Happy Birthday VAX 11/780)

by bqt＠softjar.se

On 2010-10-30 01:12, Ethan Dicks<ethan.dicks at gmail.com> wrote: > On Fri, Oct 29, 2010 at 2:26 PM, Brent Hilpert<hilpert at cs.ubc.ca> wrote: >> > On 2010 Oct 29, at 10:39 AM, Ethan Dicks wrote: >>> >> >>> >> That all depends. ?Back in the day, what we did was not demand-paged >>> >> virtual memory (something supported natively on the VAX and the 68010 >>> >> (but not effectively on the 68000)... (which is part of what >>> >> distinguishes the 68010 from the 68000 - instruction restart). >> > >> > There have been a couple of indications it was the '10 that added the >> > instruction restart, but was the implementation in the '10 bug-free? > I know it works well enough in early Sun workstations and the AT&T > Unix PC (3B1/7300), but I have no knowledge of any required > workarounds due to possible bugs. Yes, the 68010 worked fine with demand paging. The 68000 did not. Neither of them implemented instructions restarts, though. As noted below, the 68010 did instuction suspension instead. The "interesting" workarounds that I've hear of are actually 68000-related. As the 68000 could not do instruction restarts, people originally through you couldn't use it in demand paging systems. However, I think it was Apollo (but it might have been some other company) did come up with a solution. The 68000 could not restart an instruction, nor suspend them and later resume. However, you could stall the processor indefinitely. Using their own designed MMU (there were none from Motorola for the 68000), and a second CPU, Apollo made the primary CPU stall on a page fault, and the secondady CPU wake up. The secondary CPU could then do a page in. Once the page was available, the primary CPU was allowed to continue. (One alternative version of the design that I heard was that the secondary CPU would run in parallel with the primary, but slightly behind, so that it could be interrupted before starting to execute the instruction causing a page fault, and then you'd have the saved state before the page fault in the secondary CPU, but I don't think that this is a plausible design). >> > I didn't deal with the problem directly, heard about it from some friends >> > who were programming around it, and it would have been 1989, so long after >> > the 00->10 transition. My recollection about the issue was there was a bug >> > under certain conditions that was fixed in the next version, as distinct >> > from a 'new feature', but perhaps it was just the way the problem was >> > described to me or the way I understood what was being said. > I have no memory of issues with instruction restart on the '10, but I > didn't use that feature of the chip when I was doing embedded product > development 20+ years ago (we only used it for the "loop mode" > 1-instruction cache feature that allowed so-called "DBcc loops" to run > ~50% faster due to not needing fetch cycles while in the loop). > > Could what you remember be something to do with "instruction restart" > vs "instruction continuation"? (a distinction I was not making, but > now that I've read this - > http://www.easy68k.com/paulrsm/doc/dpbm68k1.htm - perhaps that's a > better way to describe it). They are two different things, yes. But they serve the same purpose. It's just different ways of dealing with what to do after a page fault (or any trap from which you want to recover). The advantage of instruction continuation, especially with the 68010, is that it didn't introduce any incompatibilities with the 68000. If you had implemented instruction restarts instead, you would have had to introduce a bunch of new registers in the CPU that kept track of partial modifications done before the trap, so that you could undo them before restarting the instruction. With instruction continuation, it's all preserved internally in the CPU without exposing the software to anything new. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

15 years, 10 months

3
2
0 0

manual for M9312 bootstrap module

by jack.rubin＠ameritech.net

Can anyone provide an electronic copy (or link) to the DEC publication, EK-M9312-TM-002 M9312 Bootstrap-Terminator Module Technical Manual? The previous link at http://www.computer.museum.uq.edu.au/unfinished/ no longer seems to work. Thanks, Jack

15 years, 10 months

2
1
0 0

VCFMW Pics and Shirts

by silent700＠gmail.com

It's been a week since VCFMW and now we've got some galleries to display! You can find them at vcfmw.org. I have video from the abortive uStream broadcast that I still need to chop up (it made a 2.8gb .flv file!) but will post as soon as I can. I'm not at all happy with the video or audio quality, so different methods will be employed next year. We still have a stock of shirts remaining. The design can be seen here: http://picasaweb.google.com/Silent700/VCFMW50OfficialGraphics#5512512730455… If anyone would like one, they are $15 incl. shipping in the US (talk to me if you're international.) Here are the sizes we have left (you can tell which we'll order more and less of next year :) Same yellow design on black or Navy-Blue Gildan pre-shrunk cotton shirts: Blue M: 2 Black M: 1 Black L: 11 Black XXL: 8 Blue XXL: 3 Blue XXXL: 2 Thanks and see you next year! -j

15 years, 10 months

2
2
0 0

cctalk Digest, Vol 86, Issue 71

by dm561＠torfree.net

Date: Sun, 31 Oct 2010 12:47:06 -0500 From: "MikeS" <dm561 at torfree.net> Subject: Re: cctalk Digest, Vol 86, Issue 68 ----------------- Sorry about that (sending the digest); no idea how that got sent, will make sure it doesn't happen again. Humbly apologetic, mike

15 years, 10 months

1
0
0 0

Memory mapped I/O

by bqt＠softjar.se

On 2010-10-30 23:18, Brent Hilpert<hilpert at cs.ubc.ca> wrote: > On 2010 Oct 30, at 12:34 PM, Dave McGuire wrote: > >> > On 10/30/10 1:08 PM, Chuck Guzis wrote: >>> >> Aside from expanding program storage, the large addressing space was >>> >> used to map file space (another type of "memory-mapped I/O"), so file >>> >> access was actually performed through the paging hardware/software. >>> >> That was kind of cool, as the STAR was a memory-to-memory vector >>> >> machine, so you could use vector instructions on entire files, rather >>> >> than have to issue reads and writes for pieces of a file. >> > >> > That functionality is in use all over the place today as mmap(), >> > accessing files as if they were memory, pushing the read/write burden >> > out into the VM system. It's extremely effective. > I remember in the 80's (programming primarily on BSD (and VMS)) > thinking it would nice to have that functionality, how easy it would > make a lot of file-access programming, and that it would be easy to add > on a VM system. Of course, I was in ignorance of the prior histories > such as the STAR that Chuck mentions. A few years later a friend would > tell me about the new mmap function in unix. This might very well be totally wrong, but I remember hearing about it at the time, that Sun (who I believe was the ones to first implement mmap()) bascially took the whole TOPS-20 concept and translated it to Unix. A bit surprised no TOPS-20 hackers have spoken up yet... This was around for a long time on the PDP-10 before this. Not sure how it correlates timewise to CDC and the STAR though. But no matter if Unix took it from TOPS-20 or not, there is no denying that TOPS-20 had this a long time before it came to Unix. >> > I'd not consider it to be "memory-mapped I/O" at all, though, in the >> > context of "a processor reading and writing I/O ports". Sure, file >> > I/O is a sort of I/O, and mmap() and similar techniques map that file >> > I/O into the address space, but the context of this discussion...and >> > indeed, most, it not all use of the term "memory-mapped I/O" doesn't >> > refer to this sort of thing. > Well, Chuck did say "a type of". If files are a form of abstracted disk > I/O, then mmap is a form of abstracted memory-mapped I/O. Memory mapped files are kindof neat, but it's not I/O at all in one way. After all, all you do is just leave the actual I/O to the virtual memory system instead of doing it yourself. So it's not that the I/O is done in any different way, it's just initiated by someone else. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

15 years, 10 months

2
1
0 0

Repairing core memories....

by gerhard.kreuzer＠liftoff.at

Hi, Please let me know any outcome of this project, I also have some stacks, 8/L and 8/e of unknown condition and would be some day in the situation to start repair. Thanks a lot, and much success!! With best regards Gerhard -----Urspr?ngliche Nachricht----- Von: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] Im Auftrag von cctalk-request at classiccmp.org Gesendet: Sonntag, 31. Oktober 2010 19:37 An: cctalk at classiccmp.org Betreff: cctalk Digest, Vol 86, Issue 71 Send cctalk mailing list submissions to cctalk at classiccmp.org To subscribe or unsubscribe via the World Wide Web, visit http://www.classiccmp.org/mailman/listinfo/cctalk or, via email, send a message with subject or body 'help' to cctalk-request at classiccmp.org You can reach the person managing the list at cctalk-owner at classiccmp.org When replying, please edit your Subject line so it is more specific than "Re: Contents of cctalk digest..." Today's Topics: 1. Re: Need to find parts 82S23 / 74S188 (Chuck Guzis) 2. Re: [OT]? Sun Ultra 60 (Zane H. Healy) 3. Re: Large geometry MFM drive testing (Chuck Guzis) 4. Re: [OT]? Sun Ultra 60 (Dave McGuire) 5. Re: [OT]? Sun Ultra 60 (Zane H. Healy) 6. Re: [OT]? Sun Ultra 60 (Alexandre Souza - Listas) 7. Re: [OT]? Sun Ultra 60 (Alexandre Souza - Listas) 8. Re: Need to find parts 82S23 / 74S188 (Alexandre Souza - Listas) 9. Re: CDC STAR was: Happy Birthday VAX 11/780 (influence of) (Chuck Guzis) 10. Re: Need to find parts 82S23 / 74S188 (Eric Smith) 11. Re: cctalk Digest, Vol 86, Issue 68 (MikeS) 12. Re: Virtual memory (Johnny Billquist) 13. Re: Memory mapped I/O (Johnny Billquist) 14. Re: Repairing core memories.... (O. Sharp) ---------------------------------------------------------------------- Message: 1 Date: Sun, 31 Oct 2010 10:11:39 -0700 From: "Chuck Guzis" <cclist at sydex.com> Subject: Re: Need to find parts 82S23 / 74S188 To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Message-ID: <4CCD40DB.19611.F4760 at cclist.sydex.com> Content-Type: text/plain; charset=ISO-8859-1 On 31 Oct 2010 at 8:28, Glen Slick wrote: > On Sat, Oct 30, 2010 at 2:40 PM, Chuck Guzis <cclist at sydex.com> wrote: > > > The bigger problem for me would be finding a programmer for these > > things. ?I've got a mess of SN74S471s and no way to program them. > > > I have the Nat Semi DM74LS471 on the device list of my programmer, but > not the SN74S471. Any chance the programming algorithms are the same? They probably are. Somewhere in the history of TI part numbers, they changed some of the bipolar memories from the SN74xxx part number to TBPxxx. I can't recall which way my parts are labeled, but they're 471s under the hood. --Chuck ------------------------------ Message: 2 Date: Sun, 31 Oct 2010 10:12:31 -0700 From: "Zane H. Healy" <healyzh at aracnet.com> Subject: Re: [OT]? Sun Ultra 60 To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>, General Discussion: Message-ID: <p06240808c8f34f3401a1(a)[192.168.1.157]> Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 12:06 PM -0400 10/31/10, Dave McGuire wrote: >On 10/31/10 6:35 AM, Alexandre Souza - Listas wrote: >>Hmmm, is an Ultra 60 offtopic? :o) > > WAY off-topic. Some of us would debate that. I personally think the Ultra 2 and the Ultra 60 as two of Sun's greatest machines. They're practical to own, and take processors that will make them fairly useful. I'm also pretty fond of Sparc 20's. My Ultra 60 has dual 450Mhz CPU's, it's far more practical than my SunBlade 1000 (to much electricity used, and heat generated). My only problem is I've never gotten a Copper GigE card. >>Just got one (eee!!!), > > Cool! Agreed! >>now what to do with that? > > Just about anything you can think of, except lots of floating point math. One comment, the older the OS the better, and OpenBSD is an option. >>I could use a keyboard and mouse from Sun, since I have none :( > > Problem solved; I'll put a set in the box I'm packing up for you. Cool! In the mean time plug in a serial terminal. The Ultra 60 is one of the few Suns I've ever used a keyboard and mouse on, though I typically used a PS/2 keyboard an mouse on mine. I have a Sun adapter that allows that, and it works with a KVM. I've not gotten any of my Sun HW set back up since we bought our house. Sun HW and a couple SGI O2's are the only real exceptions to my rule about not collecting UNIX HW. I used the Suns a lot as general purpose workstations and servers at home. Either running Solaris, or OpenBSD. Zane -- | Zane H. Healy | UNIX Systems Administrator | | healyzh at aracnet.com | OpenVMS Enthusiast | | | Photographer | +----------------------------------+----------------------------+ | My flickr Photostream | | http://www.flickr.com/photos/33848088 at N03/ | ------------------------------ Message: 3 Date: Sun, 31 Oct 2010 10:15:01 -0700 From: "Chuck Guzis" <cclist at sydex.com> Subject: Re: Large geometry MFM drive testing To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Message-ID: <4CCD41A5.8728.125D5A at cclist.sydex.com> Content-Type: text/plain; charset=US-ASCII On 30 Oct 2010 at 15:06, Steven Hirsch wrote: > All, > > I'm trying to evaluate a pile of large MFM hard drives for > functionality. I'm attaching them to a WD-1006V-MM2 controller and > running Sprinrite 4 under DOS 6.0 (using a 486 EISA motherboard). > > This works fine for drives with < 1024 cylinders, but I cannot seem to > remember (or figure out) how to surface-test drives with more > cylinders (e.g. Priam V185 with 1166). The convention when the cylinder field overflows 10 bits is to use the two high-order bits of the head field (that's why MFM, and for that matter, IDE drives max out at 64 heads when non-LBA geometry is used.). --Chuck ------------------------------ Message: 4 Date: Sun, 31 Oct 2010 13:19:35 -0400 From: Dave McGuire <mcguire at neurotica.com> Subject: Re: [OT]? Sun Ultra 60 To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> Message-ID: <4CCDA527.1050903 at neurotica.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 10/31/10 1:12 PM, Zane H. Healy wrote: >>> Hmmm, is an Ultra 60 offtopic? :o) >> >> WAY off-topic. > > Some of us would debate that. I personally think the Ultra 2 and the > Ultra 60 as two of Sun's greatest machines. They're practical to own, > and take processors that will make them fairly useful. I agree that they're two of their best designs. I just think that machines which are still pretty common in production environments, built around a modern architecture, are hardly "classic computers". That's all. > I'm also pretty fond of Sparc 20's. As am I. >>> now what to do with that? >> >> Just about anything you can think of, except lots of floating point math. > > One comment, the older the OS the better, and OpenBSD is an option. ...unless you want to use it for real work of course. (referencing "older", not OpenBSD) -Dave -- Dave McGuire Port Charlotte, FL ------------------------------ Message: 5 Date: Sun, 31 Oct 2010 10:24:16 -0700 From: "Zane H. Healy" <healyzh at aracnet.com> Subject: Re: [OT]? Sun Ultra 60 To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>, General Discussion: Message-ID: <p0624080bc8f35668b1fd(a)[192.168.1.157]> Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 1:19 PM -0400 10/31/10, Dave McGuire wrote: >>One comment, the older the OS the better, and OpenBSD is an option. > > ...unless you want to use it for real work of course. >(referencing "older", not OpenBSD) We have a production system still running Solaris 2.6 at work. I was thinking along the lines of the older the OS, the less cruft, and the better on the older hardware. For the past few years I've typically run Solaris 8 at home, though I have Solaris 10 on the SunBlade 1000. Zane -- | Zane H. Healy | UNIX Systems Administrator | | healyzh at aracnet.com | OpenVMS Enthusiast | | | Photographer | +----------------------------------+----------------------------+ | My flickr Photostream | | http://www.flickr.com/photos/33848088 at N03/ | ------------------------------ Message: 6 Date: Sun, 31 Oct 2010 15:32:37 -0200 From: "Alexandre Souza - Listas" <pu1bzz.listas at gmail.com> Subject: Re: [OT]? Sun Ultra 60 To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Message-ID: <053701cb7924$22bebc20$6600a8c0 at portajara> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response >> Hmmm, is an Ultra 60 offtopic? :o) > WAY off-topic. Sorry you all :o( >> now what to do with that? > Just about anything you can think of, except lots of floating point > math. I always wanted to run solaris, now I have a chance :oD Internet navigation in a BIG computer :oD >> I could use a keyboard and mouse from Sun, since I have none :( > Problem solved; I'll put a set in the box I'm packing up for you. W00T! :oD Thanks a lot, Dave! :oD Since it is SO offtopic, I'll direct my other questions directly to you ------------------------------ Message: 7 Date: Sun, 31 Oct 2010 15:34:28 -0200 From: "Alexandre Souza - Listas" <pu1bzz.listas at gmail.com> Subject: Re: [OT]? Sun Ultra 60 To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Message-ID: <053801cb7924$2451b830$6600a8c0 at portajara> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response > Sun HW and a couple SGI O2's are the only real exceptions to my rule about > not collecting UNIX HW. I used the Suns a lot as general purpose > workstations and servers at home. Either running Solaris, or OpenBSD. My impossible dream is to get a SGI machine. Any of them. There is an Ozone (or something like) in a surplus seller I know, but he asks just too much money for it. Someday I'll get one :oD It is a pride and joy for me to have a SGI machine on my desk :oD ------------------------------ Message: 8 Date: Sun, 31 Oct 2010 15:37:08 -0200 From: "Alexandre Souza - Listas" <pu1bzz.listas at gmail.com> Subject: Re: Need to find parts 82S23 / 74S188 To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Message-ID: <053901cb7924$25794840$6600a8c0 at portajara> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original >I have the Nat Semi DM74LS471 on the device list of my programmer, but >not the SN74S471. Any chance the programming algorithms are the same? AFAIK the algorithm is the same, the only difference is in speed/fan out ------------------------------ Message: 9 Date: Sun, 31 Oct 2010 10:54:08 -0700 From: "Chuck Guzis" <cclist at sydex.com> Subject: Re: CDC STAR was: Happy Birthday VAX 11/780 (influence of) To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Message-ID: <4CCD4AD0.28674.362B3F at cclist.sydex.com> Content-Type: text/plain; charset=US-ASCII On 31 Oct 2010 at 8:21, Jerome H. Fine wrote: > Interesting!! I worked for CDC in Toronto from around 1972 to 1977 on > the local PL-50 program. IIRC, the PL-50 was a much slower version of > the STAR-100, but with the same instruction set. Initially, the goal > was to write an operating system. I was part of the Sunnyvale mafia and worked with quite a number of your Canadian co-workers. Anil and I later partnered up on the FORTRAN compiler for the ETA-10. You probably remember that the PL- 50/STAR-65 met an unfortunate fate at the hands of the corporate "leave nothing behind" people. I witnessed firsthand, the destruction of the two STAR-1B systems a couple of years later. It wasn't pretty--a dumpster, bolt cutters and large hammers. I saved a heatsink from the power supply--there wasn't much else left intact. I begged to be allowed to take the ROS stack from one system, but no such luck. The stations were removed and sent back to Arden Hills. -- I'm going from memory on this one, but there's some STAR literature on bitsavers if you want to check my facts. 256 registers of 64 bits; if halfword mode was selected, the lower 128 were doubled and the upper 128 were inaccessible. Many registers had special meanings, including program status, cycle timer and a few others. Internally, memory was fetched 512 bits ("Super word" or "sword"; really 544 bits with ECC included) and the vector pipes were 128 bits wide (2 single-precision results per cycle). An odd machine in that scalar operations were most decidedly RISC in attitude. For example, there were only load and store register- memory operations and one had to use 2 instructions (EX and ELEN) to enter a full 64-bit immediate constant into a register. No stack or auto-increment/decremet per se; subroutine linkage was done with a sort of S/360-style LM-STM combo "swap" instruction that simultaneously stored and loaded any number of registers. The machine architecture itself was basically 3-address, so instructions were either 32 bits or 64 bits in length. Before an ECO ("Rev. R") was installed on all systems, all registers could also be addressed as the lower 256 words of user memory address space. This hugely complicated instruction scheduling and so it was determined that it wasn't needed. I know you guys used the RED OS, but we had to use STAR-OS from LLL as our base in Sunnyvale. It was basically a message-passing OS with a controller started by the job scheduler, which could have as many controllees as desired. You could send a message up the chain, one level, or to the top or broadcast to all controllees. I recall that the termination message content was the characters "ALL DONE". Regarding paging, I saw my share of DEADBEEF codes (was the STAR OS the first to use this failure code?). At some point we went from a demand-paging algorithm to a working-set one, but the stuff that the pager had to keep track of made the code a nightmare. Jim Smith suffered a lot on that thing. It didn't help that we had to scavenge time on the customer systems at LLL or hop the "noon balloon" out of San Jose to use the system at ADL. One thing that I never got to try on the 100 was seeing how long a maximum-length packed BCD divide would take. Given that the byte instruction field lengths were 16 bits, it meant either 65K or 131K digits... One memory I have is being sent to Arden Hills in January during the OPEC oil embargo and settling in for the night in the machine room at ADL because it was warmer than my room at the Ramada. I"d love to find someone who spent time on the TI ASC to compare notes... --Chuck ------------------------------ Message: 10 Date: Sun, 31 Oct 2010 11:07:43 -0700 From: Eric Smith <eric at brouhaha.com> Subject: Re: Need to find parts 82S23 / 74S188 To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> Message-ID: <4CCDB06F.9090905 at brouhaha.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 10/31/2010 10:11 AM, Chuck Guzis wrote: > On 31 Oct 2010 at 8:28, Glen Slick wrote: > > >> On Sat, Oct 30, 2010 at 2:40 PM, Chuck Guzis<cclist at sydex.com> wrote: >> >>>> The bigger problem for me would be finding a programmer for these >>>> >>> things. I've got a mess of SN74S471s and no way to program them.> >>> >> I have the Nat Semi DM74LS471 on the device list of my programmer, but >> not the SN74S471. Any chance the programming algorithms are the same? >> > They probably are. Somewhere in the history of TI part numbers, they > changed some of the bipolar memories from the SN74xxx part number to > TBPxxx. I can't recall which way my parts are labeled, but they're > 471s under the hood. > True, but it has absolutely *nothing* to do with whether a National Semiconductor DM74LS471 uses the same programming algorithm and electrical parameters as the SN74S471. They might, but it was not uncommon for different vendors to have parts that did NOT program in the same way. They often did their own designs, with different types of fuses and materials, requiring different programming parameters. Eric ------------------------------ Message: 11 Date: Sun, 31 Oct 2010 12:47:06 -0500 From: "MikeS" <dm561 at torfree.net> Subject: Re: cctalk Digest, Vol 86, Issue 68 To: <cctalk at classiccmp.org> Message-ID: <8021827792C6419AB1C1B7613E954423 at vl420mt> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original ----- Original Message ----- From: <cctalk-request at classiccmp.org> To: <cctalk at classiccmp.org> Sent: Saturday, October 30, 2010 4:18 PM Subject: cctalk Digest, Vol 86, Issue 68 > Send cctalk mailing list submissions to > cctalk at classiccmp.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.classiccmp.org/mailman/listinfo/cctalk > or, via email, send a message with subject or body 'help' to > cctalk-request at classiccmp.org > > You can reach the person managing the list at > cctalk-owner at classiccmp.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cctalk digest..." > > > Today's Topics: > > 1. Re: Happy Birthday VAX 11/780 (influence of) (Chuck Guzis) > 2. Re: TTL HEX LED driver chip (Chuck Guzis) > 3. Re: TRS-80 Model II Manuals (Fred Jan Kraan) > 4. Re: DiscFerret: First working hardware, firmware and > microcode! (Philip Pemberton) > 5. Re: TRS-80 Model II Manuals (Tony Duell) > 6. Re: TRS-80 Model II Manuals (Chuck Guzis) > 7. Re: DiscFerret: First working hardware, firmware and > microcode! (Dave McGuire) > 8. Re: Happy Birthday VAX 11/780 (influence of) (Dave McGuire) > 9. Re: DiscFerret: First working hardware, firmware and > microcode! (Philip Pemberton) > 10. Re: TTL HEX LED driver chip (Brent Hilpert) > 11. Re: Happy Birthday VAX 11/780 (influence of) (Brent Hilpert) > 12. Fall cleaning, some small machines for free (Bob Rosenbloom) > 13. Re: DiscFerret: First working hardware, firmware and > microcode! (Chuck Guzis) > 14. Need to find parts 82S23 / 74S188 (alan canning) > 15. Re: Happy Birthday VAX 11/780 (influence of) (Chuck Guzis) > 16. Re: DiscFerret: First working hardware, firmware and > microcode! (Philip Pemberton) > 17. Re: TTL HEX LED driver chip (Tony Duell) > 18. Re: Nuclear Data ND 6600 (Tony Duell) > 19. Re: TRS-80 Model II Manuals (Tony Duell) > 20. Re: TTL HEX LED driver chip (Tony Duell) > 21. Re: TTL HEX LED driver chip (Tony Duell) > 22. Re: Wanted : Monitor Capable of TTL RGB (Tony Duell) > 23. Re: I/O models (was RE: Happy Birthday VAX 11/780 (influence > of)) (Tony Duell) > 24. Re: Fall cleaning, some small machines for free (Brent Hilpert) > 25. Re: Need to find parts 82S23 / 74S188 (ben) > 26. Re: TRS-80 Model II Manuals (Geoffrey Reed) > 27. Re: Need to find parts 82S23 / 74S188 (Tony Duell) > 28. Re: Need to find parts 82S23 / 74S188 (Chuck Guzis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 30 Oct 2010 10:08:19 -0700 > From: "Chuck Guzis" <cclist at sydex.com> > Subject: Re: Happy Birthday VAX 11/780 (influence of) > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <4CCBEE93.7369.1A49AC at cclist.sydex.com> > Content-Type: text/plain; charset=US-ASCII > > On 29 Oct 2010 at 21:14, Johnny Billquist wrote: > >> If your program vrites data to address 0, and reads it back, and get >> the same data back, and another program on the same machine, at >> roughly the same time, write to address 0, and reads the same data >> back, and that data is different than the first programs data, then >> I'd say you have virtual memory. > > So, your definition ties virtual memory into multi-user access? > That's not the way I learned it. > > Consider (again folks, I'm sorry for the reference) the CDC 6600 > (circa 1964). Every user is given a relocation address (called RA) > and field length (FL) as a way of partitioning main memory. Each > user's memory addressing space is kept isolated from every other's > and this fits your definiton because one user's location X was > different from every other user's location X and there was no way for > a user to tell what his RA was; i.e. each user was safely "boxed in". > > That's not virtual memory by any stretch of the definition. Over- > committing memory meant writing/reading the entire FL of a user to > disk ("rollout" and "rollin"). > > Now consider the STAR-100 (I think it would qualify as the first > virtual memory machine of CDC), circa 1969. Every user got an > addressing space of 48 bits, but the machine itself had only > 512Kwords (64 bit) of physical storage. For production use, most of > the time the system was run in single-user mode (kept thrashing down > with large data sets). That fits my definition of VM because the > user was fooled into thinking that there was more physical memory > than there really was. > > Aside from expanding program storage, the large addressing space was > used to map file space (another type of "memory-mapped I/O"), so file > access was actually performed through the paging hardware/software. > That was kind of cool, as the STAR was a memory-to-memory vector > machine, so you could use vector instructions on entire files, rather > than have to issue reads and writes for pieces of a file. > > So I think we differ considerably in our definitions. > > --Chuck > > > > ------------------------------ > > Message: 2 > Date: Sat, 30 Oct 2010 10:21:07 -0700 > From: "Chuck Guzis" <cclist at sydex.com> > Subject: Re: TTL HEX LED driver chip > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <4CCBF193.19364.2603DF at cclist.sydex.com> > Content-Type: text/plain; charset=US-ASCII > > On the same topic here, can anyone interpret the "state table" on the > second page of the National DM74LS447 7-segment decoder datasheet? > > http://pdf1.alldatasheet.com/datasheet- > pdf/view/149198/NSC/DM74LS447N.html > > I tend to think of state diagrams as belonging to things such as > counters and don't have a clue as to what to make of the one > furnished. > > --Chuck > > > > > > ------------------------------ > > Message: 3 > Date: Sat, 30 Oct 2010 20:05:06 +0200 > From: Fred Jan Kraan <fjkraan at xs4all.nl> > Subject: Re: TRS-80 Model II Manuals > To: cctech at classiccmp.org > Message-ID: <4CCC5E52.9000802 at xs4all.nl> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Thanks to the ever-useful JP Hindin, I've obtained a set of TRS-DOS >> disks and other application disks for my TRS-80 Model II system, which >> is the entire setup pictured here, plus a bit more: >> >> http://oldcomputers.net/pics/TRS-80-II_table.JPG >> >> It's been sitting, covered, pretty much since I obtained it, but now I >> can try reviving it and actually seeing what it can do. I'm going to >> tear into it and clean the drives and so forth, document what it has, >> etc. and then boot 'er up and see what we can see. >> >> I'm looking for a copy of the Technical Ref manual for it; despite >> finding scans of the covers and so forth online, I'm unable to actually >> locate one. In addition to that, if someone has a Shugart 8" Service >> Manual, that might come in damned handy for making sure those are up to >> speed as well. >> > See > http://electrickery.xs4all.nl/comp/mirror/trs-80_archives/Manuals/Hardware/M odel_II_Technical_Reference_Manual_(1980)(Radio_Shack)(pdf).zip. > The Shugart stuff should be included. > > Essential this is from a modified copy of the files that were available > from http://www.trs-80.com/ (copied without permission). >> Many thanks, >> >> Nathan >> >> > Success, > > Fred Jan > > P.S. My own adventures with the Model II: > http://www.xs4all.nl/~fjkraan/comp/trs80m2/ > > > > ------------------------------ > > Message: 4 > Date: Sat, 30 Oct 2010 19:35:32 +0100 > From: Philip Pemberton <classiccmp at philpem.me.uk> > Subject: Re: DiscFerret: First working hardware, firmware and > microcode! > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Message-ID: <4CCC6574.8010103 at philpem.me.uk> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 30/10/10 17:26, Al Kossow wrote: >> If it's going to be an adapter, could you add holes for SA1000-style 8" >> drives (50pin/20pin cabling)? > > I almost mistook that for a floppy drive until I looked it up on > Bitsavers...! > > I can't see any real reason why SA1000 support couldn't be added to the > bridge-board. Looks like the only changes required would be: > - An oscillator to generate the 3.6866us +/- 0.1% timing clock > (270982 to 271524Hz, nominal 271253Hz). Although I have no idea what > standard crystal frequencies could be used to generate that signal. The > FPGA's PLL might be persuaded to do it, though, I'll have to check. > - Two jumpers to disconnect the Timing Clock from the ST412/506 Data > connector when these are not in use (or maybe just a second connector?) > - A 50-pin connector for the SA1000 control cable > > The extra cost probably isn't worth worrying about... though I might > have to restrict drive selection to Drive 0 only in order to get enough > I/O pins for head selection. > > Thanks, > -- > Phil. > classiccmp at philpem.me.uk > http://www.philpem.me.uk/ > > > ------------------------------ > > Message: 5 > Date: Sat, 30 Oct 2010 19:47:54 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: TRS-80 Model II Manuals > To: cctalk at classiccmp.org > Message-ID: <m1PCGTE-000J3xC at p850ug1> > Content-Type: text/plain > >> locate one. In addition to that, if someone has a Shugart 8" Service >> Manual, that might come in damned handy for making sure those are up to >> speed as well. > > ...And if they;'re not, it's most likelyto be the drive belt. Yes I know > 'up to speed' wasn't meant to be taken literally, but that seemed too > good to miss :-) > > More seriously, what model of Shugart8" drive? Are there not manuals for > them on bitsavers? > > -tony > > > ------------------------------ > > Message: 6 > Date: Sat, 30 Oct 2010 11:55:03 -0700 > From: "Chuck Guzis" <cclist at sydex.com> > Subject: Re: TRS-80 Model II Manuals > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <4CCC0797.19723.7C011E at cclist.sydex.com> > Content-Type: text/plain; charset=US-ASCII > > On 30 Oct 2010 at 19:47, Tony Duell wrote: > >> ...And if they;'re not, it's most likelyto be the drive belt. Yes I >> know 'up to speed' wasn't meant to be taken literally, but that seemed >> too good to miss :-) > > Well, he could have a 220V 50Hz model and be running it on 120V 60Hz > (the motor will develop sufficient torque to spin the disk). I've > made that mistake once. The results from the reverse would be > "interesting"... > > --Chuck > > > > ------------------------------ > > Message: 7 > Date: Sat, 30 Oct 2010 15:29:06 -0400 > From: Dave McGuire <mcguire at neurotica.com> > Subject: Re: DiscFerret: First working hardware, firmware and > microcode! > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Message-ID: <4CCC7202.6050705 at neurotica.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 10/30/10 2:35 PM, Philip Pemberton wrote: >> I can't see any real reason why SA1000 support couldn't be added to the >> bridge-board. Looks like the only changes required would be: >> - An oscillator to generate the 3.6866us +/- 0.1% timing clock (270982 >> to 271524Hz, nominal 271253Hz). Although I have no idea what standard >> crystal frequencies could be used to generate that signal. The FPGA's >> PLL might be persuaded to do it, though, I'll have to check. > > You could stick a little AD9833 (or similar) DDS chip on there. It's > overkill, but they're pretty cheap now, and you'll get the desired > frequency spot-on. > > -Dave > > -- > Dave McGuire > Port Charlotte, FL > > > ------------------------------ > > Message: 8 > Date: Sat, 30 Oct 2010 15:34:25 -0400 > From: Dave McGuire <mcguire at neurotica.com> > Subject: Re: Happy Birthday VAX 11/780 (influence of) > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Message-ID: <4CCC7341.1090704 at neurotica.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 10/30/10 1:08 PM, Chuck Guzis wrote: >> Aside from expanding program storage, the large addressing space was >> used to map file space (another type of "memory-mapped I/O"), so file >> access was actually performed through the paging hardware/software. >> That was kind of cool, as the STAR was a memory-to-memory vector >> machine, so you could use vector instructions on entire files, rather >> than have to issue reads and writes for pieces of a file. > > That functionality is in use all over the place today as mmap(), > accessing files as if they were memory, pushing the read/write burden > out into the VM system. It's extremely effective. > > I'd not consider it to be "memory-mapped I/O" at all, though, in the > context of "a processor reading and writing I/O ports". Sure, file I/O > is a sort of I/O, and mmap() and similar techniques map that file I/O > into the address space, but the context of this discussion...and indeed, > most, it not all use of the term "memory-mapped I/O" doesn't refer to > this sort of thing. > > -Dave > > -- > Dave McGuire > Port Charlotte, FL > > > ------------------------------ > > Message: 9 > Date: Sat, 30 Oct 2010 20:58:46 +0100 > From: Philip Pemberton <classiccmp at philpem.me.uk> > Subject: Re: DiscFerret: First working hardware, firmware and > microcode! > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Message-ID: <4CCC78F6.9040004 at philpem.me.uk> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 30/10/10 20:29, Dave McGuire wrote: >> You could stick a little AD9833 (or similar) DDS chip on there. It's >> overkill, but they're pretty cheap now, and you'll get the desired >> frequency spot-on. > > ?8.25 each with no quantity discount is *not* cheap. The FPGA only costs > a few quid more than that. > > Digikey have them for ?5.86, but that's still more than a crystal. I > wonder how the host adapters for the SA1000s generated this clock > frequency... it does seem somewhat odd. > > The other thing is, I'd be concerned about releasing hardware with > SA1000 support without testing it on an actual drive. I'm willing to bet > the chances of me finding a working SA1000 in 230V/50Hz configuration > are somewhere between 'slim' and 'nil'. > > I'll guarantee ST506 support though, given that I've got an ST277R RLL > drive and controller here. Just need an MFM controller for it, or the > RLL code tables for the Seagate ST21R or ST22R controller (which IIRC > uses an Adaptec AIC010 chip)... > > -- > Phil. > classiccmp at philpem.me.uk > http://www.philpem.me.uk/ > > > ------------------------------ > > Message: 10 > Date: Sat, 30 Oct 2010 13:23:00 -0700 > From: Brent Hilpert <hilpert at cs.ubc.ca> > Subject: Re: TTL HEX LED driver chip > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <8534ab06c8e0281a7fcfc54d6a70efa5 at cs.ubc.ca> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On 2010 Oct 30, at 10:21 AM, Chuck Guzis wrote: > >> On the same topic here, can anyone interpret the "state table" on the >> second page of the National DM74LS447 7-segment decoder datasheet? >> >> http://pdf1.alldatasheet.com/datasheet- >> pdf/view/149198/NSC/DM74LS447N.html >> >> I tend to think of state diagrams as belonging to things such as >> counters and don't have a clue as to what to make of the one >> furnished. > > It's obviously a state diagram for a decade counter, my guess is > someone just screwed up making the datasheet and included the state > diagram from some other device. > > > > ------------------------------ > > Message: 11 > Date: Sat, 30 Oct 2010 13:36:50 -0700 > From: Brent Hilpert <hilpert at cs.ubc.ca> > Subject: Re: Happy Birthday VAX 11/780 (influence of) > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <d40186fd9ded72a101d654d9516da0f5 at cs.ubc.ca> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On 2010 Oct 30, at 12:34 PM, Dave McGuire wrote: > >> On 10/30/10 1:08 PM, Chuck Guzis wrote: >>> Aside from expanding program storage, the large addressing space was >>> used to map file space (another type of "memory-mapped I/O"), so file >>> access was actually performed through the paging hardware/software. >>> That was kind of cool, as the STAR was a memory-to-memory vector >>> machine, so you could use vector instructions on entire files, rather >>> than have to issue reads and writes for pieces of a file. >> >> That functionality is in use all over the place today as mmap(), >> accessing files as if they were memory, pushing the read/write burden >> out into the VM system. It's extremely effective. > > I remember in the 80's (programming primarily on BSD (and VMS)) > thinking it would nice to have that functionality, how easy it would > make a lot of file-access programming, and that it would be easy to add > on a VM system. Of course, I was in ignorance of the prior histories > such as the STAR that Chuck mentions. A few years later a friend would > tell me about the new mmap function in unix. > > >> I'd not consider it to be "memory-mapped I/O" at all, though, in the >> context of "a processor reading and writing I/O ports". Sure, file >> I/O is a sort of I/O, and mmap() and similar techniques map that file >> I/O into the address space, but the context of this discussion...and >> indeed, most, it not all use of the term "memory-mapped I/O" doesn't >> refer to this sort of thing. > > Well, Chuck did say "a type of". If files are a form of abstracted disk > I/O, then mmap is a form of abstracted memory-mapped I/O. > > > > ------------------------------ > > Message: 12 > Date: Sat, 30 Oct 2010 13:36:53 -0700 (PDT) > From: Bob Rosenbloom <bobalan at sbcglobal.net> > Subject: Fall cleaning, some small machines for free > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <960487.42595.qm at web80502.mail.mud.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > > Fall cleaning! > > I have a bunch of old computers and some peripherals. Most are not tested > and I expect they may need some work to become operational, though some > may work correctly as-is. Anyway, I'm hoping to find people interested in > restoring these systems. > > There are three Burroughs B25 systems, each has a processor box, disk box, > monitor, keyboard, and power supply. There is one box of docs and > diskettes and one, very dirty, printer. > http://www.anifur.com/clist/misc-b1.jpg > http://www.anifur.com/clist/misc-b2.jpg > http://www.anifur.com/clist/misc-b3.jpg > http://www.anifur.com/clist/misc-b4.jpg > > IBM convertible, an early laptop type system. > > A Computer Products portable, thermal, serial terminal. > http://www.anifur.com/clist/misc-ptr.jpg > > A Radio Shack TRS-80 model I with expansion chassis and monitor. I believe > this has a bad power supply. > http://www.anifur.com/clist/misc-rs.jpg > > A NEC Spinwriter terminal. This is like a Diablo daisywheel terminal > except the print element is a cylinder. I know this one needs work but > does power up. > http://www.anifur.com/clist/misc-spin.jpg > > Some kind of cartridge tape system. I think it's SCSI interfaced. I don't > believe this has ever been used. > http://www.anifur.com/clist/misc-tape.jpg > > A large flatbed scanner that I also believe is unused. It's SCSI > interfaced. UMAX 3000. > http://www.anifur.com/clist/misc-scanner.jpg > > Digitech RS-232 analyzer with manuals. This runs CP/M 86 but I don't have > the boot disc for it. Does power up. > http://www.anifur.com/clist/misc-anal.jpg > > Kaypro 2, powers up and ask for a system disk. > http://www.anifur.com/clist/kaypro1.jpg > > Hitachi pen plotter. This has a parallel interface. It powers up and works > from the front panel. Light weight. > http://www.anifur.com/clist/hitachi1.jpg > > Panasonic NV-A960 VCR editing unit. > http://www.anifur.com/clist/a960-1.jpg > > Nicolet Zeta 8A pen plotter. 8 pens. Also powers up and works from the > front panel. Serial interface. > > All of these are located in the Santa Cruz, CA mountains, near the Bonny > Doon airport. I can possibly bring something into Santa Clara where I > work. Best to come visit and check them out here. I really don't want to > ship anything as I just don't have the time or energy. > > Please rescue these before I scrap them, I really need the space and these > are now outside, but covered under a Quonset hut. > > Bob > > > ------------------------------ > > Message: 13 > Date: Sat, 30 Oct 2010 13:39:13 -0700 > From: "Chuck Guzis" <cclist at sydex.com> > Subject: Re: DiscFerret: First working hardware, firmware and > microcode! > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <4CCC2001.27472.DB6112 at cclist.sydex.com> > Content-Type: text/plain; charset=US-ASCII > > On 30 Oct 2010 at 15:29, Dave McGuire wrote: > >> On 10/30/10 2:35 PM, Philip Pemberton wrote: >> > I can't see any real reason why SA1000 support couldn't be added to >> > the bridge-board. Looks like the only changes required would be: - >> > An oscillator to generate the 3.6866us +/- 0.1% timing clock (270982 >> > to 271524Hz, nominal 271253Hz). Although I have no idea what >> > standard crystal frequencies could be used to generate that signal. >> > The FPGA's PLL might be persuaded to do it, though, I'll have to >> > check. >> >> You could stick a little AD9833 (or similar) DDS chip on there. >> It's >> overkill, but they're pretty cheap now, and you'll get the desired >> frequency spot-on. > > Also, aren't the read/write data signals on the SA1000 differential? > Or do I have them confused with the ST506 interface? > > --Chuck > > > > ------------------------------ > > Message: 14 > Date: Sat, 30 Oct 2010 13:52:12 -0700 > From: alan canning <scanning.cc at gmail.com> > Subject: Need to find parts 82S23 / 74S188 > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: > <AANLkTinzHd-NW1yL2LFuNG1=1q7s3hKOdxe2VLr7uXLH at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Anybody no where to score some Sig 82S23 / Nat 74S188 parts ? I've tried > all > the usual suspects ( Ebay, local parts houses, Digikey, etc. ) with no > joy. > I believe this part was used on old S100 boards. > > Part also known as ( a.k.a. ) Fu 7111, AMD 27S18, MMI 6330, TI 18SA30 and > Harris 7602. Need this part to fix an old computer controlled RF Power > amplifier. > > Thanks for any and all help. > > Best regards, Steven > > > ------------------------------ > > Message: 15 > Date: Sat, 30 Oct 2010 13:54:40 -0700 > From: "Chuck Guzis" <cclist at sydex.com> > Subject: Re: Happy Birthday VAX 11/780 (influence of) > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <4CCC23A0.9876.E985BD at cclist.sydex.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 30 Oct 2010 at 15:34, Dave McGuire wrote: > >> I'd not consider it to be "memory-mapped I/O" at all, though, in >> the >> context of "a processor reading and writing I/O ports". Sure, file >> I/O is a sort of I/O, and mmap() and similar techniques map that file >> I/O into the address space, but the context of this discussion...and >> indeed, most, it not all use of the term "memory-mapped I/O" doesn't >> refer to this sort of thing. > > I'm sure and I'd never seriously call it "memory-mapped I/O"--but > sometimes our world seems akin to that of Humpty-Dumpty: "When I use > a word it means just what I choose it to mean--neither more nor less" > > Uh-oh, here comes another story... > > After I left CDC and the STAR project in 1977, my past came back to > haunt me in the form of doing an optimizing FORTRAN for the ETA-10 in > about 1983. We got a leased-line linkup to ETA in St. Paul and I > asked what text editor they were using. > > Much to my surprise, it turned out to be the same editor I'd written > for a lark around 1975 when the STAR had lots of really interesting > byte string instructions and I could exploit file-mapped I/O to use > them. Mind you, this was in the day of 16-line 1200 bps terminals. > > But the ETA-10 had none of those instructions, essentially having > evolved out of the "everything but the kitchen sink CISC" state of > mind of the original architecture. Some programmer had been detailed > off to replace all of those cool vector instructions with their > scalar equivalents! > > I was stunned and opined that with that way of thinking, the software > end of the ETA project was doomed. > > --Chuck > > > > ------------------------------ > > Message: 16 > Date: Sat, 30 Oct 2010 21:58:20 +0100 > From: Philip Pemberton <classiccmp at philpem.me.uk> > Subject: Re: DiscFerret: First working hardware, firmware and > microcode! > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Message-ID: <4CCC86EC.8040906 at philpem.me.uk> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 30/10/10 21:39, Chuck Guzis wrote: >> Also, aren't the read/write data signals on the SA1000 differential? >> Or do I have them confused with the ST506 interface? > > They're both differential. It's just that the SA1000 expects you to feed > it a reference clock signal. It doesn't have to be locked against > write-data, it just has to be there, and be accurate to 0.1%... > > Assuming the OEM manual is accurate, of course. > > -- > Phil. > classiccmp at philpem.me.uk > http://www.philpem.me.uk/ > > > ------------------------------ > > Message: 17 > Date: Sat, 30 Oct 2010 21:23:40 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: TTL HEX LED driver chip > To: cctalk at classiccmp.org > Message-ID: <m1PCHxn-000J3xC at p850ug1> > Content-Type: text/plain > >> >> On 29 Oct 2010 at 22:10, Tony Duell wrote: >> >> > Anyother thought I had is to use a 7447 for the lower 8 or 10 >> > patterns (as it's designed to do!) and add logic for the higher ones. >> > I don't know if that saves chips. >> >> The 7447 has a problem in that the "6" doesn't have the top crossbar, >> so that it's indistinguishable from a "b". The '247 does include the >> top segment when displaying '6', which is why I mentioned the 247 and >> not 47. > > Yes, I should have remembered that... > > >> >> This brings to mind an ancient "fix" for the 47 "6" display--a >> pulldown diode connected between segment "e" and segment "a"--in the > > Been there, done that :-) > >> display of 0-9 there is no time when segment "e" is active that >> segment "a" isn't also active. The converse, however isn't true--and >> this "fix" will mess up your display of "b" if you use the method >> described previously to display 0-F. > > Of course. For 'b' you mmed the 'e' segment without the 'a' segment. > That's what distinguishes it from '6' > > >> >> But if you allow diodes, then there's no reason not to use a 4-to-16 >> demux and a mess of diodes to do the decoding for 0-F, is there? > > while my original question didn't preclude the use of discrete > components, and while I happly ageee that the odd diodes, pull-up > resisotrs, etc can lead to interesting solutions, I do feel that such a > diode matrix is outisde the spirit of the problem. After all, you could > say it can be solved with no ICs at all, just lots of discrete > transistors, etc. :-) > > -tony > > > ------------------------------ > > Message: 18 > Date: Sat, 30 Oct 2010 21:27:54 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: Nuclear Data ND 6600 > To: cctalk at classiccmp.org > Message-ID: <m1PCI1t-000J3yC at p850ug1> > Content-Type: text/plain > >> eons ago at a TRW a friend bought a nice box that looked much like an >> ADM3a with nice case, integrated CRT and keyboard, and gleefully gave >> the guy selling it about $40 for it. This was in the day of $700 >> terminals new prices. >> >> It was a Vector graphics console. Unfortunately he had not looked at >> the back, or thru the cracks, but it was a plastic case with a keyboard >> and CRT inside, no PS, electronics or anything else. I suspect when he > > I am suprised there wasn't the standard driver circuits for the CRT (from > composite vidoe, say). My guess is that there should have been, and they > were msising. > >> moved east some years ago it got dumpstered, but it was about the same >> sort of thing, no brains in the "terminal" but in the box. > > ICL did something similar. They had 'terminals' that consisted of encoded > keyboards and composite monitors. The case was painted a horrible orange > colour ... I think I still have one of the keyboards somewhere, but I > mangaged to give the monitor away some years ago (thankfully...) > > -tony > > > ------------------------------ > > Message: 19 > Date: Sat, 30 Oct 2010 22:07:02 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: TRS-80 Model II Manuals > To: cctalk at classiccmp.org > Message-ID: <m1PCIdm-000J4HC at p850ug1> > Content-Type: text/plain > >> >> On 30 Oct 2010 at 19:47, Tony Duell wrote: >> >> > ...And if they;'re not, it's most likelyto be the drive belt. Yes I >> > know 'up to speed' wasn't meant to be taken literally, but that seemed >> > too good to miss :-) >> >> Well, he could have a 220V 50Hz model and be running it on 120V 60Hz >> (the motor will develop sufficient torque to spin the disk). I've >> made that mistake once. The results from the reverse would be >> "interesting"... > > Actaully, a lot of the 8" drives I have have 120V motors, but of course > the right pulleys for 50Hz mains. They are run from an > (auto)transformer, often the primary winding of the syatem mains > transformer. > > So I suppose he could have something like that :-) > > -tony > > > ------------------------------ > > Message: 20 > Date: Sat, 30 Oct 2010 21:41:27 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: TTL HEX LED driver chip > To: cctalk at classiccmp.org > Message-ID: <m1PCIF1-000J48C at p850ug1> > Content-Type: text/plain > >> >> On 2010 Oct 29, at 2:10 PM, Tony Duell wrote: >> > >> > For those who are wondeirng, the 'trivial' solution I mentioned uses 7 >> > off 74150 16-input multiplexers, one for each segment. You tie the >> > inputs >> > high low to determine if that segment is on or off for a given set fo 4 >> > input bits. >> > >> > After posing that, I thought of other solutions that make no >> > assumptions >> > about the segment patterns -- they always work. For example 7 off >> > 74151 8 >> > input muxes and a single inverter (1/6 of a 7404) That has the >> > advantage >> > of automatically providing actrive high and active low outputs. >> >> That only gives you 8 patterns, not 16 .. ? > > Err, no. That's what the extra inverter is for. > > You know hos to use a 2^n input mux to make an arbitrary combinartorial > function of n signals. Feed the n signals to the select inputs of the > multiplexer and wire the 'data' inputs high or low as the truth table > requires. > > But you can also yuse a 2^(n-1) input mux and maybe a single inverte, you > connect n-1 of the input lines to the select inputs of the mux. And then > for each of those combinations you consider the 2 truth table lines that > apply (the last input, the one you've not used yet, of course > distinguishes between the 2 lines in each pair). There are 4 possibilites > : > a) The output of the function is 0 in both cases (it doesn't depend on > the last input at all) --> wire that input of thr mux to ground > > b) It's 1 in both cases -> wire the input to Vcc > > c) It's 0, 1 , it follows the last input in this case -> Wire that last > input signal to the appropraite input of the multiplexer > > d) It's 1,0, it's the opposite of the last input. This is when you need > that inverter. Invert the last input signal and wire the appropriate > multiplexer input to the ouptu of the inverter. > > If oyu requre several functions of the same inputs (as here), you only > need 1 ivnerter (assumeing there are no fan-out problems), since it's > always thge same singal (say the 2^0 data input) you need to invert. > > Son yes, you can use 8 input multiplexers here (and 4 input ones if you > only want to generate 6 or 8 patterns). > > Now, another silly aside... > > If you want to use a 2^(n-2) mux, you may need any or all of the 16 > possible functions of the last 2 inputs (you split up the truth table > into sets of 4 lines, and see which function of the last 2 inputs gives > the right paattern, of course). This makes it less useful :-). But it's > made me think pof a chip that AFAIK never existed... If you think of those > 16 possible functions of 2 inputs, then 4 of them are 'trivial' in the > sense that you can produce them with no logic at all. Namely 'always 0', > 'always 1', 'equal to the A input' and 'equal to the B input'. Which > leaves 12 non-rtrivial ones/ Now that means there could have been a 16 > pin IC with 2 power pins, 2 inputs and 12 outputs, the 12 non-trivial > functions of the 2 inputs. Use that witha 74150 for an arbitrary fucntion > of 6 inputs... > > -tony > > > > ------------------------------ > > Message: 21 > Date: Sat, 30 Oct 2010 21:44:22 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: TTL HEX LED driver chip > To: cctalk at classiccmp.org > Message-ID: <m1PCIHq-000J49C at p850ug1> > Content-Type: text/plain > >> >> On 29 Oct 2010 at 16:13, Brent Hilpert wrote: >> >> > I too realised that halfway thru the exercise and went scrambling back >> > to the databook to check on the 247. >> >> Another reason to lament the passing of the hardcopy databook. I >> used to sit and read them cover-to-cover. Not really possible in > > Absolutely. Of cousre I've kept all my old paper databooks, and still > read them from time to tieme. > > Yes, it's very useful being able to get data on just about any standard > IC over the internet. But it's useful in a different way being able to > flip through a data book, see what's available, etc. I've yet to find a > manufacturer's site that lets me browse in the same way. > > -tony > > > ------------------------------ > > Message: 22 > Date: Sat, 30 Oct 2010 21:48:01 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: Wanted : Monitor Capable of TTL RGB > To: cctalk at classiccmp.org > Message-ID: <m1PCILO-000J4AC at p850ug1> > Content-Type: text/plain > >> >> On 30/10/10 03:08, Dan Williams wrote: >> > I am on the lookout for a monitor something similar to a Phillips >> > cm3388 does anyone near London have one they would like to sell or >> > trade, or know of anywhere I could get one. >> >> Surely you mean the CM8833? >> Those were fairly extensively re-badged -- Acorn, for instance, sold a=20 >> variant of the CM8833 Mk.II as the AKF17. > > Is CM8833 a TTL-input monitor? I think it was available as an option, > but most of them take analogue RGB on the SCART socket. > > Most of the time the SCART inputs, for all they're supposed to be 1V will > stand TTL (the CM8833 ones certainly will). Or since they're terminated > to ground through a 75 ohm resistor, connect a 300 Ohm (or so) resistor > in series with each TTL signal. Done that many times :-) > > Is there any reason a TV with a SCART socket isn't suitable? Most, if not > all, LCD and plasma TVs should haev RGB inputs on the SCART socket, for > example. > > -tony > > > > ------------------------------ > > Message: 23 > Date: Sat, 30 Oct 2010 21:52:09 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: I/O models (was RE: Happy Birthday VAX 11/780 (influence > of)) > To: cctalk at classiccmp.org > Message-ID: <m1PCIPM-000J4BC at p850ug1> > Content-Type: text/plain > >> >> OK, it's fair to say that there's nothing that precludes memory-mapped >> I/O = >> in any machine (except perhaps physical memory architecture, although I >> can= >> 't think of an example). But port-mapped I/O machines had specific >> instruc= > > The obvious problem would be if the memroy map is already totally full. > If you've got a Z80 systme with 64K of memory, it would be perverse to > try memory mapped I/O (you could have some kind of MMU, but why...). > Similarky trying to emmeroy map any kind of I/O on a 2MByte PERQ would be > an 'interesting' exercise... > > -tony > > > > ------------------------------ > > Message: 24 > Date: Sat, 30 Oct 2010 14:09:44 -0700 > From: Brent Hilpert <hilpert at cs.ubc.ca> > Subject: Re: Fall cleaning, some small machines for free > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <981998b8f30737dece941bd3fc38a0c1 at cs.ubc.ca> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On 2010 Oct 30, at 1:36 PM, Bob Rosenbloom wrote: >> >> Panasonic NV-A960 VCR editing unit. >> http://www.anifur.com/clist/a960-1.jpg > > I dismantled one of these a few years ago, it contained an > (NEC-branded) 8080, a whack of NEC 8255's (PIO), half-a dozen ceramic > Fujitsu MB8516's (2K*8 EPROMS, 2716-like), all socketed, for anyone > that might take an interest in such stuff. > > >> All of these are located in the Santa Cruz, CA mountains, near the >> Bonny Doon airport. I can possibly bring something into Santa Clara >> where I work. Best to come visit and check them out here. I really >> don't want to >> ship anything as I just don't have the time or energy. >> >> Please rescue these before I scrap them, I really need the space and >> these are now outside, but covered under a Quonset hut. >> >> Bob > > > > ------------------------------ > > Message: 25 > Date: Sat, 30 Oct 2010 15:11:06 -0600 > From: ben <bfranchuk at jetnet.ab.ca> > Subject: Re: Need to find parts 82S23 / 74S188 > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Message-ID: <4CCC89EA.1000405 at jetnet.ab.ca> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > looks for 74S188 with google > http://www.futurlec.com/Memory/74S188pr.shtml > > > ------------------------------ > > Message: 26 > Date: Sat, 30 Oct 2010 14:17:16 -0700 > From: Geoffrey Reed <geoffr at zipcon.net> > Subject: Re: TRS-80 Model II Manuals > To: cctalk <cctalk at classiccmp.org> > Message-ID: <C8F1D96C.2E65E%geoffr at zipcon.net> > Content-Type: text/plain; charset="US-ASCII" > > Y'all are making me miss my tandy model 16 and 6000. > > > > > ------------------------------ > > Message: 27 > Date: Sat, 30 Oct 2010 22:21:08 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: Need to find parts 82S23 / 74S188 > To: cctalk at classiccmp.org > Message-ID: <m1PCIrQ-000J3xC at p850ug1> > Content-Type: text/plain > >> >> Anybody no where to score some Sig 82S23 / Nat 74S188 parts ? I've tried >> all >> the usual suspects ( Ebay, local parts houses, Digikey, etc. ) with no >> joy. >> I believe this part was used on old S100 boards. >> >> Part also known as ( a.k.a. ) Fu 7111, AMD 27S18, MMI 6330, TI 18SA30 and >> Harris 7602. Need this part to fix an old computer controlled RF Power >> amplifier. > > IIRC, this is a PROM, 32*8 I think. Do you have a copy of the data to > program into it? A blank chip is not a lot of use to you otherwise... > > Also while all the derives you've mentioned are I think compatible when > being read (that is, as they are normally used in the circuit), the > programming algorithms are different for differnet manufacturers. You need > to get one that your programmer can handle > > -tony > > > ------------------------------ > > Message: 28 > Date: Sat, 30 Oct 2010 14:18:38 -0700 > From: "Chuck Guzis" <cclist at sydex.com> > Subject: Re: Need to find parts 82S23 / 74S188 > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <4CCC293E.2099.FF7864 at cclist.sydex.com> > Content-Type: text/plain; charset=US-ASCII > > On 30 Oct 2010 at 13:52, alan canning wrote: > >> Anybody no where to score some Sig 82S23 / Nat 74S188 parts ? I've >> tried all the usual suspects ( Ebay, local parts houses, Digikey, etc. >> ) with no joy. I believe this part was used on old S100 boards. >> >> Part also known as ( a.k.a. ) Fu 7111, AMD 27S18, MMI 6330, TI 18SA30 >> and Harris 7602. Need this part to fix an old computer controlled RF >> Power amplifier. > > If you'd like something a bit closer to home, you might try ACP-- > they're listing some IM5603s on eBay for $7.95 the each. > > --Chuck > > > > End of cctalk Digest, Vol 86, Issue 68 > ************************************** ------------------------------ Message: 12 Date: Sun, 31 Oct 2010 11:37:47 +0100 From: Johnny Billquist <bqt at softjar.se> Subject: Re: Virtual memory To: cctalk at classiccmp.org Message-ID: <4CCD46FB.6070304 at softjar.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 2010-10-30 23:18, "Chuck Guzis"<cclist at sydex.com> wrote: > > On 29 Oct 2010 at 21:14, Johnny Billquist wrote: > >> > If your program vrites data to address 0, and reads it back, and get >> > the same data back, and another program on the same machine, at >> > roughly the same time, write to address 0, and reads the same data >> > back, and that data is different than the first programs data, then >> > I'd say you have virtual memory. > So, your definition ties virtual memory into multi-user access? > That's not the way I learned it. No no no. You miss my point. It don't directory tie in to multiuser access. It's about presenting to you a memory which in reality does not exist as you perceive it. As a follow on benefit of this is the fact that you can have multiple instances at the same time. But that is not the definition. The definition is that you appear to have a linear space of memory that maps the whole virtual address range, and that this memory is yours alone. It is your own private memory. Just as a virtual machine is your own private machine. No matter the fact that in reality, this is not the case, and your memory (or machine) is just something running under the control of an underlying operating system, which gives you this service. > Consider (again folks, I'm sorry for the reference) the CDC 6600 > (circa 1964). Every user is given a relocation address (called RA) > and field length (FL) as a way of partitioning main memory. Each > user's memory addressing space is kept isolated from every other's > and this fits your definiton because one user's location X was > different from every other user's location X and there was no way for > a user to tell what his RA was; i.e. each user was safely "boxed in". The important question here - are the programs aware of the RA register, and can they change it? And can they address the full range of memory addresses as perceived by the program. > That's not virtual memory by any stretch of the definition. Over- > committing memory meant writing/reading the entire FL of a user to > disk ("rollout" and "rollin"). Another word for swapping in and out? Anyway, I'm not sure if this would qualify as virtual memory or not without knowing a few more details. But it might very well be virtual memory, as far as I can tell. > Now consider the STAR-100 (I think it would qualify as the first > virtual memory machine of CDC), circa 1969. Defined by whom? CDC? Or you guys? ;-) > Every user got an > addressing space of 48 bits, but the machine itself had only > 512Kwords (64 bit) of physical storage. For production use, most of > the time the system was run in single-user mode (kept thrashing down > with large data sets). That fits my definition of VM because the > user was fooled into thinking that there was more physical memory > than there really was. You know, my definition and yours don't necessarily disagree on all points. Both would define the VAX as having virtual memory (well, except for the fact that yours might not, if you have a VAX with enough physical memory). We just disagree about what when there is more physical memory than you have virtual memory space. For you, that means it can't be virtual memory. but for me it can. For me, what is relevant is whether the program is presented with his own private memory space, which contains all addresses he can address, and where all those addresses are valid and working. A memory space which he don't have to share with anyone else. That's what virtual memory is, as opposed to physical memory, which you can point at, and which all running code on a computer needs to live on. And that means that the OS is always there. And possibly other processes as well. Using the same addresses you are. If that means that you cannot have your own memory for a specific address, then it's not virtual memory. But then you probably aren't talking about virtual memory either, but physical memory. > Aside from expanding program storage, the large addressing space was > used to map file space (another type of "memory-mapped I/O"), so file > access was actually performed through the paging hardware/software. > That was kind of cool, as the STAR was a memory-to-memory vector > machine, so you could use vector instructions on entire files, rather > than have to issue reads and writes for pieces of a file. > > So I think we differ considerably in our definitions. On some parts, yes. So, do the VAX not have virtual memory? After all, I can fill a VAX with more physical memory than you can address virtually. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ------------------------------ Message: 13 Date: Sun, 31 Oct 2010 11:47:53 +0100 From: Johnny Billquist <bqt at softjar.se> Subject: Re: Memory mapped I/O To: cctalk at classiccmp.org Message-ID: <4CCD4959.8040105 at softjar.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 2010-10-30 23:18, Brent Hilpert<hilpert at cs.ubc.ca> wrote: > On 2010 Oct 30, at 12:34 PM, Dave McGuire wrote: > >> > On 10/30/10 1:08 PM, Chuck Guzis wrote: >>> >> Aside from expanding program storage, the large addressing space was >>> >> used to map file space (another type of "memory-mapped I/O"), so file >>> >> access was actually performed through the paging hardware/software. >>> >> That was kind of cool, as the STAR was a memory-to-memory vector >>> >> machine, so you could use vector instructions on entire files, rather >>> >> than have to issue reads and writes for pieces of a file. >> > >> > That functionality is in use all over the place today as mmap(), >> > accessing files as if they were memory, pushing the read/write burden >> > out into the VM system. It's extremely effective. > I remember in the 80's (programming primarily on BSD (and VMS)) > thinking it would nice to have that functionality, how easy it would > make a lot of file-access programming, and that it would be easy to add > on a VM system. Of course, I was in ignorance of the prior histories > such as the STAR that Chuck mentions. A few years later a friend would > tell me about the new mmap function in unix. This might very well be totally wrong, but I remember hearing about it at the time, that Sun (who I believe was the ones to first implement mmap()) bascially took the whole TOPS-20 concept and translated it to Unix. A bit surprised no TOPS-20 hackers have spoken up yet... This was around for a long time on the PDP-10 before this. Not sure how it correlates timewise to CDC and the STAR though. But no matter if Unix took it from TOPS-20 or not, there is no denying that TOPS-20 had this a long time before it came to Unix. >> > I'd not consider it to be "memory-mapped I/O" at all, though, in the >> > context of "a processor reading and writing I/O ports". Sure, file >> > I/O is a sort of I/O, and mmap() and similar techniques map that file >> > I/O into the address space, but the context of this discussion...and >> > indeed, most, it not all use of the term "memory-mapped I/O" doesn't >> > refer to this sort of thing. > Well, Chuck did say "a type of". If files are a form of abstracted disk > I/O, then mmap is a form of abstracted memory-mapped I/O. Memory mapped files are kindof neat, but it's not I/O at all in one way. After all, all you do is just leave the actual I/O to the virtual memory system instead of doing it yourself. So it's not that the I/O is done in any different way, it's just initiated by someone else. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ------------------------------ Message: 14 Date: Sun, 31 Oct 2010 14:22:35 -0400 (EDT) From: "O. Sharp" <ohh at panix.com> Subject: Re: Repairing core memories.... To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Message-ID: <Pine.NEB.4.64.1010311349420.17597 at panix3.panix.com> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sun, 31 Oct 2010, Jos Dreesen wrote: > So I have these 2 PDP-8/L core stacks I am trying to recover: > > One would be perfect, if bit 3 @ adr 0 would be alive... > Although this is 99.99% OK, it is of course not good enough. Just to mke sure I'm hearing you right: Are you saying one individual core is 100% dead, and everything else is 100% okay? If so - if it's one single, individual core which is broken - I'd suspect this is pretty much irrepairable. The options would be to A) try to form/mold/create a new ferrite core around the wires, which would be insanely difficult assuming it could be done at all, or B) to unwire that plane of the core stack, replace the broken ferrite core with a new one, and then rethread/rewire it. That's extremely nontrivial work, I have to believe. But they were originally threaded by hand, albeit by people with microscopes and _very_ good eye-hand coordination and sewing skills, so it's within the realm of possibility. If I've read you wrong, though, and the whole thing is working except address 0 bit 3 is working _some_ of the time, that would be really good news. :) You could try scoping out the sense amps and inhibit drivers for bit 3 and see if they were just borderline to specifications, something which might be just tweaky enough to affect one bit. > The other stack seems to be a total loss : > 2 sense wires are open circuit, more than 20 select diodes shorted. Of > course the further quality of the cores is unknown. Oddly enough, this one might be easier to deal with. Have you tracked down where the sense wires go open-circuit? If they're failing at a solder-joint near an outer edge, you could potentially repair them without having to open up the whole damn stack. The diode replacement would likely mean partially disassembling the stack assembly to gain access to both sides of the diode PCB, but at least you're only having to dig in one level. O'course making those repairs might simply reveal more problems at the core level. But you've gotta start somewhere, I s'pose. :) > Is there any realistic way of getting one fully functional stack out of these > ? > > Removing a single core from the really bad stack to the almost OK stack would > seems almost feasible to me, since address 0 is bound to be on a edge of a > core mat. I suspect I'm not the only one on the list who: -thinks opening up a core-stack and repairing it is theoretically possible; -also thinks it would be a hell of a daunting project; -is somewhat amazed at the dexterity and patience of the people who originally hand-wired them at manufacture; and -thinks pulling off a repair of a core-plane by rewiring it by hand would give significant bragging rights. :) -O.- End of cctalk Digest, Vol 86, Issue 71 **************************************

15 years, 10 months

1
0
0 0

2026

2025

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