test-drb

test-drb@ccmp.vtda.org

101090 discussions

by elson＠pico-systems.com

Message: 20 Date: Sun, 01 Apr 2012 00:29:09 -0700 From: Jeff Woolsey <jlw at jlw.com> To: cctech at classiccmp.org Subject: Re: Pertec interface Message-ID: <4F7803C5.1050404 at jlw.com> Content-Type: text/plain; charset=ISO-8859-1 SimH also describes bad blocks, which have the high-bit set in the length but otherwise look normal. Except that most tape drives, without heroics, will not give you any data for an unrecoverable read error (both that and a tapemark read as 0-length blocks; some gymnastics are needed to tell them apart), except that such a block cannot be empty. So what to put in it, if we're noting them at all? I'm playing with ANSI-style labels for this. Some history is at: http://neil.franklin.ch/Usenet/alt.folklore.computers/20001209_New_Tape_Con… , though in there it is asserted that tape blocks cannot be longer than 64K, implying that only two bytes are required for the length. However, I have a tape someone else wrote (HDR2 even says so) with 65536-byte blocks (not every O/S today can handle that--16-bit signed comparisons). To represent that along with 0-byte tapemarks requires 17 bits. Elsewhere someone asserted that a tape block can be as long as the entire tape, which seems unlikely and wouldn't always fit in three bytes. I think most Pertec formatted drives will not give you the bad block, but I could be wrong. Of course if it is really bad, even the block length can't be determined. Most PDP-11 and VAX tape controllers, both DEC and third-party could handle 65536 byte blocks. Of course, on a PDP-11, that could be the entire memory in a single tape block! So, it really only made sense on Q-22 systems. Tapes with insanely long blocks are not a good idea, even on hardware that can handle it. I'm guessing 1401 and similar machines could do crazy stuff like that due to their stream of digits architecture. But, having an entire tape with only one LRCC and CRC byte would lead to undetected errors and difficult to recover files. The greatest feature of GCR is that the redundancy data is added periodically within the block, making the likelihood of recovering small dropouts much better. Jon

14 years, 1 month

For sale: warehouse of IBM, WANG, DIGITAL, NCR in Maine

by tosteve＠yahoo.com

Attention! For sale: Looks like a warehouse of IBM, WANG, DIGITAL, NCR in Bangor, Maine. See pics here: http://66.147.242.85/~oldcompu/maine/ Also some TRS-80, Apple, Compaq, etc. I have no connection, just passing on the info. Contact Penny at: peifen196 at yahoo.com Enjoy!

14 years, 1 month

What's that TeK Box?

by holm＠freibergnet.de

http://www.tiffe.de/images/Unbenannt.JPG This is one of the things in Dortmund, anyone know what this could be? Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

14 years, 1 month

PIXAR Image Computer Panel Museum Display on Ebay

by michael.99.thompson＠gmail.com

>Dave McGuire mcguire at neurotica.com >On 03/25/2012 02:50 PM, James Gessling wrote: >> Isn't this just a piece of plastic with a logo embossed in it? And >> why does anyone think Red's Dream is so great anyway? I'm not >> bidding. > > The whole computer would've been much more interesting. If the >starting price weren't so high, I'd have placed a bid just out of >sympathy for someone with such a wife. > > -Dave I thought that the RICM had one of these. It turns out that we have two PII-9 systems that they were made after the Viacom Systems buyout so it doesn't say Pixar on the die-cast front cover. I will add more pictures and details shortly. http://www.ricomputermuseum.org/Home/equipment/pixar-image-computer -- Michael Thompson

14 years, 1 month

Pertec interface

by elson＠pico-systems.com

Well, I did the bit reversal TWICE, so of course the end result was wrong! Fixed that, fixed up a little bug in resetting the file mark detection flag in the wrong place, and I now have a rough program that maps the files structure of a tape. here's a snip of what I got. VOL1RT1101 DD%% 1 HDR1SAMBR .CTL RT110100010001000100 00000 00000 000000RT11 file 0 had 2 blocks 0 errors 0 timeouts blocksize was 512 HDR1SAMBR .BAK RT110100010001000100 00000 00000 000000RT11 file 1 had 2 blocks 0 errors 0 timeouts blocksize was 512 HDR1SAMBR .FOR RT110100010001000100 00000 00000 000000RT11 file 2 had 4 blocks 0 errors 0 timeouts blocksize was 512 and so on. (Note the RT11 header labels above. I sort of thought this tape would have been >from RSX-11M, but it must have been made before we switched. Whew, that's going BACK a ways, about 1976 or 77 when we went to RSX. The actual tape I'm reading was a 6250 BPI copy of the original tape (probably 1600 BPI) from back then. This copy was probably made 15 years ago, though.) I'm now working on a program to move the entire tape to a single disk file with pretty much verbatim bytes from the tape. It will have a 32-bit header for each record of file mark, showing the record size or file mark. Then I can write programs at my leisure to extract files without having to listen to the wail of the Gast vane pump in the keystone tape drive. Oh, the performance seems to be pretty good. it was streaming fairly well at either 25 or 75 IPS in 6250, I suspect it will certainly stream at 75 IPS with a 1600 BPI tape. Jon

14 years, 1 month

PRIME NUMBERS

by jgessling＠yahoo.com

In fact those guys at the LHC Were going to do just that. By directing the beam at a block of chrystilan silicon ( nice square latice) and then Stepping the beam deflection in integer increments. A physical Erathones sieve can be created for large numbers. Essentially blasting away nonprimes. Detecting the remaining primes is then A radiation problem similar to that used in Genetic screening. Regards, Jim

14 years, 1 month

PDP-8 questions

by jgessling＠yahoo.com

Please don't use real rosewood for the side panels.?? Forests around the world are being destroyed for this increasingly rare commodity. Thanks, Jim

14 years, 1 month

Arcturus Minicomputer

by jon.griver＠gmail.com

*Dear Rod,* ** *Feeling nostaligic, I googled 'Arcturus Minicomputer', and your letter below was the only reference I found. I know the letter is from 2007. I hope the email address is still in use.* ** *I programmed an Arcturus minicomputer at the Atkinson Morley Hospital in Wimbledon from 1973 to 1976. It was used to do image processing on pictures >from the first CT scanner in the world, which was located in that hospital.* ** *All the programming I did on the machine was in assembler. The computer did not have a disk operating system. Every action involved first loading the program you need from paper tape, then the data, etc.* ** *The first thing I did was to write a very rudimentary disk operating system. It took 6 weeks, but it worked.* ** *I knew that Arcturus had installed the monitor system in Gatwick.* ** *Best Wishes,* ** ** *Jon Griver* ** ** ** *Fri Mar 30 02:45:49 CDT 2007* - Previous message: On topic? Looking for old computer book <http://www.classiccmp.org/pipermail/cctech/2007-March/037565.html> - Next message: NeXTstep: cloning a drive <http://www.classiccmp.org/pipermail/cctech/2007-March/037495.html> - *Messages sorted by:* [ date ]<http://www.classiccmp.org/pipermail/cctech/2007-March/date.html#37488> [ thread ]<http://www.classiccmp.org/pipermail/cctech/2007-March/thread.html#37488> [ subject ]<http://www.classiccmp.org/pipermail/cctech/2007-March/subject.html#37488> [ author ]<http://www.classiccmp.org/pipermail/cctech/2007-March/author.html#37488> ------------------------------ Hi All Whilst sitting on the plane on the way back from Newcastle yesterday. It reminded me of a system I saw at Gatwick airport in the early 1970's. I'm pretty sure it was run by a mini computer called an 'Arcturus'. I can clearly remember the grey rack mounted box with its row of toggle switches and lamps. I was there to install a VDU (sometimes referred to as a glass teletype). The big teletype they drove it from made the whole place shake and the VDU I fitted of course did not. It drove the departure / arrival TV monitors. The way it generated the characters was curious to say the least. It had a large number of circuits which generated parts of characters. One did a vertical bar, another produced a whole circle whilst others output parts of a circle, forty-five degree bars and so on. For each character cell the component parts of the required character were selected summed and added to a TV raster. Does anybody remember the Arcturus? Rod Smallwood

14 years, 1 month

New software for the Nintendo Entertainment System

by mwichary＠gmail.com

> > Isn't this a day early? You?re most likely in one of the late timezones. :?) Marcin

14 years, 1 month

Tape Storage Formats (was: Pertec interface)

by cruff＠ruffspot.net

At work (National Center for Atmospheric Research), we commonly stored tape contents in the Cray COS blocked data set format. It is pretty reasonable as it contains record and block control words that allow you to seek both forward and backward within the dataset, and to retain tape marks as end of file or end of dataset marks. There were many tapes containing historical weather observations ingested and stored on the Mass Storage System (MSS) in this format. While the MSS has been replaced by an HPSS archive, most of the 2 PB of data were migrated into it, so undoubtedly there are still COS blocked data set tape images in the archive. If anyone has data stored in this format, I do have some C code that will read and write it.

14 years, 1 month

cctech Digest, Vol 103, Issue 45

by michael.99.thompson＠gmail.com

> From:?Ric Barline <rbarline at mac.com> > To:?cctech at classiccmp.org > Date:?Fri, 30 Mar 2012 14:26:27 -0700 > Subject:?help with H11 and H27 > Hi. Brand new to this list. I joined because based on your past posts I believe you guys might be able to help me with my problem. I just acquired an old Heathkit system consisting of an H19 terminal, an H11 computer, and an H27 disk drive. I have managed to get the H19 and H11 talking to each other (see my short video at http://www.youtube.com/watch?v=SzZ3HHd1V3o&feature=youtu.be but I don't have any documentation for the H27 so I don't know how to use it with the H11. ?I have two floppies that came with it (actually I have a bunch that came with it as shown in my photo gallery http://gallery.me.com/rbarline#100619), one titled "Softech UCSD H11 System Disk" and one titled "Softech UCSD System H11 Utilities". > > Can anyone help me figure out what to type on the terminal in order to get the disk drive to start the boot process? Thanks in advance. The Rhode Island Computer Museum has the same system, but no software. https://sites.google.com/a/ricomputermuseum.org/home/Home/equipment/heathki… It would be great if you could make images of the diskettes and send them to Al Kossow for archiving. -- Michael Thompson

14 years, 1 month

New software for the Nintendo Entertainment System

by swtpc6800＠comcast.net

Google Maps will release a version for the 8-bit Nintendo Entertainment System. http://www.youtube.com/googlemaps It appears that the NES has a problem with the cartridge connector. Michael Holley

14 years, 1 month

help with H11 and H27

by rbarline＠mac.com

Hi. Brand new to this list. I joined because based on your past posts I believe you guys might be able to help me with my problem. I just acquired an old Heathkit system consisting of an H19 terminal, an H11 computer, and an H27 disk drive. I have managed to get the H19 and H11 talking to each other (see my short video at http://www.youtube.com/watch?v=SzZ3HHd1V3o&feature=youtu.be but I don't have any documentation for the H27 so I don't know how to use it with the H11. I have two floppies that came with it (actually I have a bunch that came with it as shown in my photo gallery http://gallery.me.com/rbarline#100619), one titled "Softech UCSD H11 System Disk" and one titled "Softech UCSD System H11 Utilities". Can anyone help me figure out what to type on the terminal in order to get the disk drive to start the boot process? Thanks in advance.

14 years, 1 month

Making music with computer hardware...

by alhartman＠yahoo.com

Bohemian Rhapsody http://www.youtube.com/watch?v=Ht96HJ01SE4?

14 years, 1 month

OSI boot disks

by dfnr2＠yahoo.com

I've got my OSI C2-4P into a basically working state, to the point where the boot code seeks to track 0 and tries to load the OS boot code.? I know I had a couple of plastic disk-boxes with my OSI boot disks and some software, but I cannot find it anywhere.? I do have some C1 Boot disks, but these won't work with a C2.? If anyone with a working OS65D boot disk (and hopefully the tutorial disks) for a C2/4/8 would be willing to make some copies for me, I'd be most grateful. I believe it's possible to reconstruct a boot disk over a serial port, but I'd rather keep that as a last resort.? That would be an exercise much like building a ship in a bottle. Thanks, Dave

14 years, 1 month

TRS-80 Model II TRSDOS: paranoia strikes deep

by eric＠brouhaha.com

It looks like the developers of TRS-80 Model II TRSDOS were very paranoid that someone might be able to bypass the filesystem and access data on a floppy directly. I'm not sure if their primary concern was file password protection, or if they had other reasons. Obviously you could write a program that accesses the floppy directly, by talking to the FDC and DMAC chips yourself, and there's not really anything that can be done to prevent that. Oddly enough, this was exactly *opposite* to what Apple did in Apple DOS. Apple published the APIs to read and write sectors (RWTS), but never published the "File Manager" APIs that allowed access to the file system through means other than passing commands through the character output vector (e.g., the BASIC statement PRINT CHR$(4);"OPEN FOO"). I'll mostly describe how things work in Model II TRSDOS 1.2, the earliest version I've been able to obtain. I haven't studied 2.0 nearly as much yet. The TRSDOS 1.2 "kernel" consists of three parts, while later versions are more monolithic. The Model II boot ROM loads all of drive 0 track 0 (single density, 26 sectors of 128 bytes) into memory starting at 0e00. First it looks for the four characters "DIAG" at 1400 and "BOOT" at 1000. If either are missing, it refuses to proceed. It calls the code at 1404, which in TRSDOS is a simple hardware diagnostic. When that returns, it jumps to the first stage boot loader code at 1004. Some other operating systems don't bother with a diagnostic, and just start their boot code at 1404, never returning to the ROM. The first stage boot loader actually understands the TRSDOS filesystem enough to find the directory entries of files in TRSDOS load module format, and load them into memory. In 1.2, it loads "IODVRS/SYS" and then "TRSDOS/SYS", and jumps into the latter. The Model II TRSDOS filesystem is similar in many regards to that of Model I TRSDOS, but not enough to actually be compatible. Unsurprisingly, it looks like an intermediate step in the evolution from Model I TRSDOS to Model III TRSDOS. As in Model III TRSDOS, files can only have a single directory entry, with a limited number of extents. IODVRS/SYS contains, as the name implies, the low level I/O drivers for the system, including the keyboard, display, printer, and floppy drives, the dispatching for system (SVC) calls, and a few utility SVCs. However, it only contains the SVC handlers for services 0-28, the I/O functions and basic utility SVCs. Note in particular that it contains no file system code. IODVRS/SYS is conceptually similar to the CP/M BIOS, though lacking CP/Ms charming simplicity. IODVRS/SYS provides several undocumented SVCs for internal use by TRSDOS, including floppy subsystem initialization (13), floppy sector read (14), and floppy sector write (16). Note that at the time IODVRS/SYS is loaded, no call is made into it to initialize it. TRSDOS/SYS, however, is called after being loaded. It basically performs the TRSDOS initialization that only has to happen at boot time. It has another implementation of filesystem reading and load module format handling, very similar to what is present in the stage 1 boot, but now instead of talking to the FDC and DMAC directly, it uses the undocumented floppy SVCs described previously. After various initialization, it loads SYSRES/SYS and jumps into it. SYSRES/SYS contains the filesystem code and other relatively high-level TRSDOS infrastructure code. It generally relies on SVC calls into IODVRS/SYS to perform all I/O, and has very little other dependence on IODVRS/SYS internals. This is conceptually similar to the CP/M BDOS. It loads system overlays to handle some SVCs and user commands. Overlays SYS0/SYS through SYS9/SYS are small overlays, occupying one disk granule (five sectors) and loading into 2200-26ff. Other overlays may be larger, and load at 2800 or higher. Many of the overlays *do* depend on knowledge of the internals of SYSRES/SYS, directly accessing subroutines and data structures without the use of vector tables or the like. This means that SYSRES/SYS and the overlays must have been built at the same time, and would generally not be interchangeable with earlier or later releases. Anyhow, getting back to the paranoia part. Someone apparently decided that simply not documenting the SVCs that provide sector-level access to the floppy was not sufficient to thwart those that might want to bypass the filesystem. After TRSDOS/SYS uses those SVCs for its part in the boot process, it actually *removes* them from the SVC vector table, and sets up jumps to them at undocumented internal TRSDOS locations 1130 (read sector) and 1133 (write sector). In TRSDOS 1.2, access to all of the system files, including overlays, is done through the file system. The system files have normal file system entries. Unlike Model I TRSDOS, neither the system file directory entries nor the file contents need to be in any special location on the disk. In TRSDOS 2.0, things are much more monolithic. The stage 1 boot code only loads and jumps into a single file, SYSRES/SYS. The boot code does not care where this file is located, but other parts of the system do. All of the overlays, small and large, are stored in a single file, SYSTEM/SYS, which is required to start on the track after the primary directory. The first sector of SYSTEM/SYS contains a kind of overlay directory that gives the track and sector numbers at which each overlay starts. There is perhaps some advantage to putting all of the overlays in a single file, since the number of directory entries on the diskette is limited to 96. However, the need for a second, special directory mechanism for overlays is ugly, even if it is only a simple one. Requiring the system files to be at fixed locations on the disk (at least relative to the primary directory) might be a reasonable requirement if it yielded some performance gain, but it generally doesn't. (With 1.2, the system files are set up when the disk is formatted, so even though they *could* be anywhere, in practice they are grouped together.) TRSDOS 2.0 introduced changes to the disk organization, such that TRSDOS 1.2 and 2.0 diskettes are not interchangeable, except that the 2.0 XFERSYS utility can convert a 1.2 diskette to 2.0 format. The disk organization changes are basically gratuitous, and don't provide any benefit to the user, while obviously being a great inconvenience to users with TRSDOS 1.2. They mashed the GAT (granule allocation table) and HIT (hash index table), which were sectors 1 and 2 of the directory track in 1.2, into just sector 1 in 2.0. In 1.2, the directory occupied sectors 3-26, while in 2.0 it occupies sectors 2-25. The only apparent rationale for doing this is to free up sector 26 on the directory track. In TRSDOS 1.2, sector 26 was not used on any track but the directory track, for any purpose. In TRSDOS 2.0, sector 26 of *every* track is used to store five bytes of unique disk ID, to better detect disk changes. (it has been suggested that those bytes might also have been used for software copy protection.) However, rather than mashing the GAT and HIT together, which made it impossible to support larger disks such as double-sided disks, they easily could have special cased the directory track(s) and stored the disk ID in either the GAT or HIT sector. TRSDOS 4.0 introduced much larger changes to the disk organization, in order to support double-sided disks and hard disks. I haven't yet begun to dig into the 4.0 code. Eric

14 years, 1 month

"Art"

by robert＠irrelevant.com

http://www.etsy.com/listing/95511758/vintage-1960s-ibm-disk-platter-aged-to *Sobs*

14 years, 1 month

S-100 MS DOS Support board PCBs

by LYNCHAJ＠YAHOO.COM

Hi I have ten (10) remaining S-100 MS DOS Support board PCBs left in case anyone would like one or more. http://s100computers.com/My%20System%20Pages/MSDOS%20Board/MSDOS%20Board.htm This board should dramatically improve MS DOS compatibility on the S-100 bus using an S-100 8086 CPU board. It can be used by any 8 or 16 bit CPU. Basically it is the guts of a PC/AT motherboard minus the CPU, RAM, and ISA slots. Thanks and have a nice day! Andrew Lynch

14 years, 1 month

FT: Data General Novas and Desktop Generation (revised from 3/22/12 post)

by js＠cimmeri.com

{revision of first CCTalk post on 3/22/12} Thanks to those who have been inquiring on these items, I can now render a more helpful post. Location: Washington, D.C., or near Frederick, Maryland. For trade (preferred) or best offers: - 1974 DG Nova 2 rackmount (untested, unrestored) top cover missing .Front panel (cosmetics very good condition) .Nova 2 CPU .Standard Memories 16k core .Basic I/O -- all electronics working condition unknown, but appear undamaged in very good condition. - 1971 DG Nova 1200 rackmount (untested, unrestored) w/ all covers. .Front panel (cosmetics -- fair condition) .Nova 1200 CPU .DG 4k core .Basic I/O -- all electronics working condition unknown, but appear undamaged in very good condition. - 1984 DG Desktop Generation R20 (untested, unrestored) w/ D461 terminal .dual power supply unit .R20 SPU unit with SPU, 256k ram, USAM, and asynch modules -- (note: no terminal cables or adapters.) .single drive diskette unit .hard drive unit .tape drive unit .manuals (setting up, testing, users in 2 encased binders) and 3 diskettes. -- all electronics working condition unknown, but appear undamaged in excellent condition. -- cosmetics, very good to excellent. PM me with trades, offers, questions, corrections. Looking for (in order of priority): - PDP 11/04 or 11/34 half-height (only) chassis, complete with PSU, covers, backplane, cables. No CPU or other logic boards needed. - HP 35721A monochrome monitor - Emulex TC12 tape controller or similar: Unibus->Pertec interface which emulates a "TS" device - ribbon cables for above -- controller -> Pertec-formatter tape drive. - Unibus ESDI controller - Pro/Venix docs (I'm using version 1.0 on a DEC Pro 350). - MFM drives: . CDC Wren II 9415-* . CMI CM-5412 . IMI 5012H . Maxstor XT-2085 . Micropolis 1324A . Priam V170 or V185 Thank you, John Singleton p.s. to check my reputation, see my ebay handle "MdntTrain".

14 years, 1 month

another hidden pdp11

by jonas＠otter.se

On Thu, 29 Mar 2012 19:57:58 +0100 (BST), ard at p850ug1.demon.co.uk (Tony Duell) wrote: > Which has just suggestesd a totally OT queestion to me. Some cultures > prohibit the drinking of alcohol. This is normally taken to mean drinks > containing ethanol. But how do they handle other -OH molecules in foods? Those cultures, and their rules prohibiting the drinking of alcohol, are quite old AFAIK. Without knowing any details of their history, it would seem logical to me to assume that they would not be aware of the presence of other -OH molecules, so they would have no special rules about them. I suppose the rules are religious? If so, some of them may well be reasonable for health reasons, but others would be illogical or based on misconceptions of physical facts. /Jonas

14 years, 1 month

You should have senn this..

by holm＠freibergnet.de

So far as I know this is MIDI ofer an arduino board: http://www.youtube.com/watch?v=Xk_XaJ7gE4Q Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

14 years, 1 month

Machine to identify

by alberto＠a2sistemi.org

I've to identify this machine. No label, no data on it. http://www.fondazionegalileogalilei.it/museo/collezioni/calcolatori/mini _pc/img_mini_pc/57_patent_pending.jpg Someone know this machine ? Alberto ------------------------------------------------------ Alberto Rubinelli - Fondazione MUSEO DEL COMPUTER Onlus Via Costantino Perazzi 22 Tel 0321 1856032 28100 NOVARA (NO) - ITALY Fax 0321 2046034 Mobile +39 335 6026632 Sito web : http://www.museodelcomputer.org Mail : alberto at museodelcomputer.org Filiale di Torino : Tel 011 23415829 Filiale di Roma : Tel 06 98357066 ------------------------------------------------------ Le telefonate con numero nascosto sono filtrate Calls with no caller identifier are filtered ------------------------------------------------------

14 years, 1 month

Pertec interface

by elson＠pico-systems.com

Well, I am chugging along on this project. After fixing a few bugs, I now have a program that will read single blocks off the tape. Somewhere the docs got confused, they say that bit zero is MSB and bit 7 is LSB, a la IBM 360. But, the data I am getting is clearly the opposite bit order, so I will reverse that. Also, I am not detecting file marks, but see a block with zero length. So, I need to look at that. Could easily be a wiring error. But, I manually reversed the bits and I get VOL1 and HDR1 records of 80 byte length, and then data records of 8192 length. So, with just a little bit more tinkering, I think this thing is going to work. It IS a nightmare, with a 44-pin TSOP memory chip glued upside down on a piece of perfboard with wire wrap wires soldered to it. It was the only suitable memory chip I could find. 64K x 16, I'm only using one byte worth. Jon

14 years, 1 month

Rosewood

by robert.jarratt＠ntlworld.com

> -----Original Message----- > From: cctalk-bounces at classiccmp.org [mailto:cctalk- > bounces at classiccmp.org] On Behalf Of Mouse > Sent: 29 March 2012 05:13 > To: cctalk at classiccmp.org > Subject: Re: PDP-8 questions > > > cylindrical volume of about 50 cubic metres for one tree. Let's say > > that one person wants a piece of rosewood that is 50cm x 50cm x 1cm. > > That is 0.0025 cubic metres, so a single fully grown tree would > > satisfy 20,000 people once a year. > > That's assuming that (a) all the pieces can be fit into the tree's volume with > no waste, (b) nothing is lost in cutting them out, and (c) any part of the tree > is perfectly suitable for any use. Neither (a) nor (b) is likely to be true, and, > while I don't know rosewood, I know that with the woods I do know > something about, (c) is not true. > > I have nothing but wild guesses as to how much is wasted; for what it's > worth, my wild guess is that the wastage is at least half the volume. > > /~\ The ASCII Mouse > \ / Ribbon Campaign > X Against HTML mouse at rodents-montreal.org > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B Yes, two people have challenged my assumptions. That is to be expected really as I am no expert on wood. It was just about getting an approximation to show that the "how can little old me really make a difference" attitude *can* make a difference when there are a lot of "little old me's". I am sure that the yield is far from perfect, but I was just trying to show that even with some fairly optimistic assumptions this attitude can have a big effect; if yield is 50% then the figures double etc.... Regards Rob

14 years, 1 month

OT: Family health issues (was: Re: another hidden pdp11)

by mtapley＠swri.edu

At 1:13 -0500 3/29/12, Tony wrote: >s/pub/hospital/ I'm really sorry to hear that, Tony. You have our sympathy and best wishes for a speedy and complete recovery for your father. Is there anything else any of us can do? -- - Mark 210-379-4635 ----------------------------------------------------------------------- Large Asteroids headed toward planets inhabited by beings that don't have technology adequate to stop them: Think of it as Evolution in Fast-Forward.

14 years, 1 month

Jump to page:

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