In article &lt;a06200716c07334d433cb(a)[192.168.1.199]&gt;9]>, "Zane H. Healy" <healyzh at aracnet.com> writes: I found that Manx has gobs of docs for gigi, so you could read the Installation and Owner's Manual in PDF format. Speaking of serial graphics protocols, does anyone on the list have a device that supports NAPLPS ("nap-lips" - North American Presentation Layer Protocol Syntax)? <http://en.wikipedia.org/wiki/NAPLPS> There is mention of a "Sceptre NAPLPS terminal from AT&T". -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

At 10:09 PM 4/24/2006, Chuck Guzis wrote: Wasn't there a Commodore 64 program that tried to handle NAPLPS, too? Sure enough, from CES '84, from my old friend Peggy Herrington: http://pegboard.com/modules.php?name=Content&pa=showpage&pid=10 - John

In article <200604242009490932.974927C2 at 10.0.0.252>, "Chuck Guzis" <cclist at sydex.com> writes: OK, I don't know what the "Fortune Systems terminal" is, but being a freak about terminals I want to know! Do tell? workstations for the Fortune 32:16? That looks like a pretty cool micro for 1982. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

In article <200604242126390197.978F7BED at 10.0.0.252>, "Chuck Guzis" <cclist at sydex.com> writes: What was the microprocessor in the terminal? Do you still have one? :-) -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

In article <200604242240190363.97D2ED61 at 10.0.0.252>, "Chuck Guzis" <cclist at sydex.com> writes: Did you code in an easter egg with your initials? :) -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>

Richard wrote: At one time you could get a software package to turn your PC into a NAPLPS display device. Here in Canada you could get NAPLPS display terminals but they were as slow as hell. They also stuck to TV output resolution - 256 color 320 x 200. 1200 baud download / 300 baud upload I belive.

My experience with Ghost is that if it doesn't understand the particular file structure on the disk being copied that it will do a raw type of copy. That is by partition. It can understand one partition (for example) and deal with files and not understand a second partition and do a raw copy of it. That is common on disks with hibernation partitions that are specific to manufacturers. Tom Uban wrote:

Hi, Tom, *********** REPLY SEPARATOR *********** On 24-Apr-06 at 22:29 Tom Uban wrote: <snippety> There exists dedicated software that is designed to do a bit-for-bit copy under such conditions. One of my favorites, mainly because it'll do a lot more than just copy, is SCSI Mechanic (yes, it'll work on IDE drives as well). Details on such may be found here: http://www.scsimechanic.com/ I've run it under Windows 2000 without any problems. If the OS can see the drives, SM should be able to work with them. File system and format are utterly irrelevant if you don't need to actually access the disks through Windows. Just as a recent example, I've used SM to make image file copies of the hard drives from several Telenex serial data analyzers, built in the mid-90's. They use a highly-customized Unix variant for their operating system. SM under W2K had no trouble at all creating bit-for-bit image files, or backup copies to another drive. There are other ways besides SM. I also own a dedicated hardware-level drive duplicator, and there are other software packages as well. Some examples are: http://www.drive-image.com/ http://www.acronis.com/homecomputing/products/trueimage/ (though I will freely admit I'm not a big fan of Acronis products). There is a big list of free utilities at this link: http://www.thefreecountry.com/utilities/backupandimage.shtml Happy hunting. -=-=-=-=-=-=-=-=-=-=-=- Bruce Lane, Owner & Head Hardware Heavy, Blue Feather Technologies -- http://www.bluefeathertech.com kyrrin (at) bluefeathertech do/t c=o=m "If Salvador Dali had owned a computer, would it have been equipped with surreal ports?"

Someone mentioned g4u: http://www.feyrer.de/g4u/ It's a boot floppy / CD. It can send images via ftp across a network if you like, or it can copy to local drives. - John

On Tue, 25 Apr 2006 20:15:51 -0400 Brad Parker <brad at heeltoe.com> wrote: The Linux /dev/hda device is a _block_ device. Data read from / written to that device goes through the buffer cache. Such devices are not considered "raw". There is no corresponding _character_ device /dev/rhda, that bypasses the buffer cache. These unbuffered character devices are the "raw" devices. -- tsch??, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

On Wed, 26 Apr 2006, Jochen Kunz wrote: Under Linux: # man 8 raw Christian

At 08:15 PM 4/25/2006 -0400, Brad Parker wrote: Because there aren't any raw disk devices, at least not by default and my google searches on the subject confirmed this. Of course as this thread has discussed, the meaning of raw I/O and the reasons for it vary, so I'll clarify. I am copying a 40GB disk to a 100GB disk and when finished, would like to have the first 40GB of the 100GB disk match the original 40GB disk, bit for bit. Neither disk has any DOS, Windows, NT, Un*x, or Linux data structures present, so no partition information, MBR data structures, etc. Yes. By "raw I/O", I was meaning that I don't want any interpretation of the disk as a file system, etc. Under Un*x, the block device typically requires that the disk be initialized with a filesystem, the disk be mounted, etc. The raw device provides access to the disk without any of this and allows the disk to be initialized with a partition table and filesystem... In years past, on non-PC platforms, I too have done this without any difficulty. I believe that the heritage of the PC is throwing a wrench into the works. By "intact", I mean that the bits on the destination drive (at least the first 40GB) match those which are on the source drive, identically. When I did the copy under linux, I used /dev/hda and /dev/hdb as you describe. Under NetBSD, I used /dev/rwd0d and /dev/rwd1d. Note that the linux /dev/hda device entry is a "block" device and the NetBSD /dev/rwd0d device entry is a "raw" (or character) device. As an old Un*x kernel developer, this is what I meant by "raw I/O" -- sorry for any confusion. Apparently it is a mechanism which allows the use of the underlying hardware's DMA capabilities to do the transfers, or at least that is my impression. Yes, sorry about the confusion here. I initially attempted to use the /dev/rwd0a and /dev/rwd1a devices which would normally be the first partition on the drive (if it were partitioned). I did this after trying to use the 'c' partition, which on all of the platforms which I used in the past designated the "whole" drive. After some searching and responses from others on another list, I discovered that on the PC the 'd' partition represents the "whole" drive and that is what I used. An update on my current results is that using NetBSD on the raw device was only slightly better than my results with linux. I am guessing that this is due to a difference in where the copy terminated at the end of the source drive due to a difference in cylinder/block alignment or something. As of yet, neither method has produced the results that I am looking for. I thought that the IDE drives these days were just a logical stream of blocks and that disk geometry was no longer a consideration. A reply on this thread by JBG seems to confirm this, but perhaps there is still some sort of translation going on due to the difference in sizes of these two disks? I have noted that the 40GB disk is LBA and the 100GB disk is LBA48. After trying the G4U utility suggested by John, which is really just a nicely wrapped NetBSD boot with some simple tools that utilize 'dd' and such, it looks like my problem is that the 40GB drive has some uncorrectable data errors in the middle of the disk and these have been stopping the copy prematurely. As the PC screen does not allow scrollback and is only a small number of lines I had not gathered that the completions were short and due to data errors rather than just errors due to reaching the end of the media and I was too lazy until now to work harder to understand what was really going on. So it would seem that both linux and NetBSD are both working similarly. In order to attempt to copy as much of the data as possible without a huge amount of human interaction, looking for errored blocks and copying around them, I tried using the 'dd' command with the 'conv=noerror' option under both the NetBSD and G4U systems and found that the option was disabled. Fortunately when I booted the linux system and tried this option, it did not complain. So the disk copy is underway again as I type this and hopefully this time it will complete the entire copy minus some bad blocks... --tom

At 07:00 PM 4/26/2006 +0200, Jochen Kunz wrote: When I run 'dd if=/dev/rwd0d of=/dev/rwd1d bs=64k conv=noerror' on NetBSD, the command reports 'dd: conv option disabled' and exits. FWIF: The linux 'dd' completed with the 'conv=noerror' option set and the report from 'dmesg' indicated 85 bad sectors in a total of 4 groups. It looks like I need to do the copy again with the 'sync' option set as you suggest if I want to maintain the file offsets between the two images. Thanks for pointing this out... --tom

At 03:33 PM 4/26/2006 -0400, der Mouse wrote: Yes, you are probably correct on this, even though it is the CD version instead of the floppy version. I believe that the traditional NetBSD 'dd' does include this feature. The reason that I'm using the installation version is that I am using on a PC chassis which is normally used to run Windows and am removing the boot drive and replacing it with the two drives to be copied. I then just boot the system from CD and go. I see. --tom

Possibly. I know it was talked about, but I don't recall anyone doing it (which does not, of course, mean nobody did). Such a thing probably would be just what this person needs ("probably" here approximately equals "unless it was done with stripped-down binaries", which seems unlikely to me). /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Tom Uban wrote: well, if you dd the base (unpartitioned) device on linux that's what you'll get. the block caching will have no effect on your copy (except perhaps to speed it up). the raw device on unix is designed to eliminate the effects of caching but in this case (a straight copy) the raw device on bsd unix and the block device would yield exactly the same output. I would disagree. the block device knows nothing about file systems. again, I disagree. This is not the case. the block device provides the same access. I think you are attaching more semantics to the raw device (and the block device) than are there. The block device has a purpose which is outside the scope of this discussion. When you read it with dd it acts just like the old unix raw device. I don't see that. ok. I think they didn't match because you used the wrong device nodes. i've worked with block devices on *bsd, sunos, solaris and linux. I think I get it. if you did "dd if=/dev/hda of=/dev/hdb" you got what you asked for. how did you determine it was not "intact"? really? how are you defining success? they are. that's just the size of the block number. if they are both LBA then they are a stream of blocks. Have you tried "dd if=/dev/hda of=/filesystem/file"? That will (I promise) copy every block off the disk attached to /dev/hda into a file. It is possible to confuse linux with kernel args which force it to believe a bogus geometry, but I doubt you are doing that, so the IDE subsystem is going make it's own determination as to the size of the drive and give you every block there is. oh wait. you didn't mention that. "dmesg" will show kernel messages and those should have been seen on the console. try "dmesg | more" yes, errors can and probably will stop the copy. I should probably just have erased this message (or read it all first). sorry. -brad

Tom Uban wrote: I missed something here .. why didn't dd work for you? I've always used something like dd if=/dev/hda of=/dev/hdb bs=512. Why is raw disk I/O capability needed? (Shouldn't the built-in support to read and write blocks be enough?) Mike

Jules Richardson wrote: Simply put, Linux (well, all the common Linux filesystems) wants a partition to end on a cylinder boundary. Two drives of different geometries, even if they're the same size, will have differing block counts per cylinder. That means that if I do a block-level dd to a disk with different geometry from the source disk, the data will be valid, but the partitions will probably not end on cylinder boundaries and the filesystems will forever be inconsistent as far as the kernel and fsck are concerned. Doc

Sometimes even worse than that. I have one machine that apparently simply won't work if a disk over some size (64G? I don't know the exact limit) is touched by the BIOS - it wedges. But if I tell the BIOS there's nothing there and let the OS kernel find it, it works fine. (I remarked on this to a vendor I know who told me my motherboard was so old it wasn't surprising it wasn't comptaible with newer disks. Gee, it was all of what, three years old. Oh well, another reason - as if I needed more! - to avoid peecees.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Mon, 24 Apr 2006 22:29:36 -0500 Tom Uban <uban at ubanproductions.com> wrote: rwd0a is a partition. You have to use rwd0d for the whole disk. (On non-i386 machines you have to use rwd0c.) -- tsch??, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

Was this in any way related to RIP graphics being used by some BBS's in the Amiga days? Cheers, Bryan

On Apr 24, 2006, at 8:08 PM, Zane H. Healy wrote: Do you have DWMotif on any of your VMS systems? If so, DECterm will emulate a vt340 and display ReGIS graphics (color!). All you need is the software to drive it. (And images to display.) Mike