test-drb

test-drb@ccmp.vtda.org

101090 discussions

by dhquebbeman＠theestopinalgroup.com

> I don't think that would work. I've cooked EPROMs for months > without any change in their functioning. So did a partner of mine.... using a homemade eraser made from a UV sterilizer unit taken from a scrapped dialysis machine. It was an Intel eprom, a 2732 or 2764, ceramic case, quartz window. The embedded system we were developing was an auto- mated knife sharpener (not to be a consumer product). During debugging, we had the prototype out of the case. Things were working fine and it was time for the first install into the van (which would drive from restaurant to restaurant doing the knife sharpening thing). Put unit in case, fire up, no operation. Take unit out of case, fire it up, everything works. We looked for warping of the PC board, kinking of cables, and all sort of things that coould glitch the unit out. Nada. Finally, thinking that we were only going to see how the case was screwing with the PC board from inside the assembled unit, we cut an access panel in the aluminum, and shined a flashlight inside. It happened to hit the EPROM window and voila! the unit starts running. After a long call with Intel engineers, it was determined that too much UV could fry the EPROM such that it would only function correctly when light was shining onto the substrate through the window! An EPROM that was afraid of the dark. To get the prototype out the door, we built it a night-lite, and everything was fine. -doug quebbeman

25 years, 11 months

Defining Disk Image Dump Standard

by allisonp＠world.std.com

>Sellam Ismail <foo(a)siconic.com> writes: >> But can you dedcode 6&2 encoded bytes in realtime on a 6502? Something >> tells me it's not fast enough to do this. > >If you're clever enough, you can do it. I previously cited several packages >that did it. Cant speak for the 6502, but NS* did it with minimal hardware a few years earlier and it was a respected design. Not a whole lot of ttl on the board either considering it was S100, Boot prom and FDC. Allison

25 years, 11 months

OT: Looking for Cap'n Crunch 2600Hz whistle

by SUPRDAVE＠aol.com

In a message dated 6/2/00 2:31:30 AM Eastern Daylight Time, foo(a)siconic.com writes: > On Fri, 2 Jun 2000, David Vohs wrote: > > > I'm sorry I can't help you find one. But I hope that you are looking for > > them only for their collectable value. I think that AT&T, and any other > > phone company, has probably long since removed this nice little "feature" > > from the computers that run the lines. So if you're looking to make some > > free phone calls, I don't think it will work. But then again, I don't work > > > for a phone company, so I could be completely wrong on this. > > C'mon, give me a break. I don't even think the youngest of fools can be > that naive :) > > No, this is purely for historical reasons. I'm developing an exhibit > around the now legendary (and now very useless) "blue box". > > Sellam back then, the telco used electromechanical systems which were easy to hack and get away with. nowadays, it's electronic with much more automation and security so its harder to cover one's tracks. i think red boxes still work, but some COCOTs have been modifed to prevent this. DB Young hurry, hurry, step right up! see the computers you used as a kid! http://members.aol.com/suprdave/classiccmp/museum.htm

25 years, 11 months

HP 7000 - What is it?

by mrdos＠swbell.net

Does anyone know anything about a HP 7000 Series computer? I don't know a lot about old HP systems. Do y'all think it's worth getting? Thanks, Owen

25 years, 11 months

OT: Looking for Cap'n Crunch 2600Hz whistle

by netsurfer_x1＠hotmail.com

>I'm looking for one of the original Cap'n Crunch cereal >whistles that >could produce the 2600Hz tone. If you >know the story of John Draper >(a.k.a. Cap'n Crunch) then >you know what I'm talking about. > >I'd also like to get a hold of the box the whistle came >in. I'm also >looking for the October 1971 issue of >Esquire magazine that featured the >article with John >Draper talking about the "blue box". > >If anyone has any idea where I might find these items, >please e-mail me >directly at <sellam(a)vintage.org>. > >Thanks! > >Sellam International Man >of Intrigue and >Danger >--------------------------------------------------------->---------------------- >Looking for a six in a pile of nines... > > Coming soon: VCF 4.0! > VCF East: Planning in Progress > See http://www.vintage.org for >details! I'm sorry I can't help you find one. But I hope that you are looking for them only for their collectable value. I think that AT&T, and any other phone company, has probably long since removed this nice little "feature" >from the computers that run the lines. So if you're looking to make some free phone calls, I don't think it will work. But then again, I don't work for a phone company, so I could be completely wrong on this. Best of luck either way. ____________________________________________________________ David Vohs, Digital Archaeologist & Computer Historian. Home page: http://www.geocities.com/netsurfer_x1/ Computer Collection: "Triumph": Commodore 64C, 1802, 1541, FSD-1, GeoRAM 512, Okimate 20. "Leela": Macintosh 128 (Plus upgrade), Nova SCSI HDD, Imagewriter II. "Delorean": TI-99/4A. "Monolith": Apple Macintosh Portable. "Spectrum": Tandy Color Computer 3. "Boombox": Sharp PC-7000. ____________________________________________________________ ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

25 years, 11 months

Please help ID this Mac board--I hope it's old enough for the list!

by jruschme＠mac.com

> From: Stan Perkins <stan(a)netcom.com> > Subject: Please help ID this Mac board--I hope it's old enough for the list! > > Hello all, > > I just came across this small PCI type board, labeled: If it's what I think, it's actually a PPC 601 PDS (processor direct slot) card. > APPLE COMPUTER INC. > 820-0510-A c1993 > > It also has a chip on it with the label: > > 341S0021 > c 1983-93 Apple > ^ > | > |-----That's why I'm hoping it's old enough to qualify :-) Not that old... but none the less... > Anyway, on one side of the PCB it's got four large quad flat pack chips, > from Philips, TI, VLSI, and BT, and on the other side (with the Apple > labeled chip I mentioned earlier) it has two rows of 8 each Toshiba > TC528128BJ-80 RAM chips. On the back end it has a DB-15F connector (like > the old Apple monitor connector) and two round DIN connectors labeled "S > IN" and "S OUT" with 7 female contacts each. Sounds like the AV card for the 1st-generation (NUBUS) PowerMacs (6100/7100/8100). > It came in a box labeled DOS Compatibility Card for Macintosh, but I'm > beginning to think it's not. More likely, someone removed it from an AV 6100 to install the DOS card. Interesting find, though... > Any clues are greatly appreciated! You're welcome. <<<John>>>

25 years, 11 months

Defining Disk Image Dump Standard

by yakowenk＠cs.unc.edu

My two cents, in decreasing order of sanity. Maybe it's a little far from the original goal*, but for the cost of a few extra bytes in track/sector numbers, the same format might handle the contents of hard disks. And there's probably a lot fewer "whacko" formatting concerns with those than with floppies - 99.44% of the time, just getting a big pile of sectors might be as much as you'd need. AFAIK, nobody wrote quarter-tracks on hard disks, or tried to copy- protect software by making bad sectors, or any similarly-goofy stuff. And machines that used hard disks didn't generally fixate on the number of tracks or sectors. (How much of that is true? Discussion?) My reaction to XML et al is generally negative too, and also not for any good reason that I could put my finger on. Maybe it seems like it would be work to parse, and I like to imagine my poor old 8-bitters being able to make use of the images themselves, not just the recipients of an end-product that was produced by a modern machine that digested the image. As I said, it's not entirely a rational concern; those old 8-bitters could do it just as well as any modern machine, given enough time and storage and programming... Maybe that's it, coding up an XML parser for a CoCo seems like it would be much more work than having some byte-by-byte record definition. So maybe you XML supporters need to hit that point a little harder. Speaking of which, maybe some compressed representation of repeated identical sectors could be good. If a floppy was 10% full, and the remaining sectors were full of some "empty" byte pattern, It would be nice if those "empty" sectors didn't take up space in the image. Of course, the image could just omit sectors, but then you'd need intelligence to decide which sectors to omit; almost as bad as needing to know which files to keep. The only way to be safe is to get it all, and maybe take advantage of patterns in the data to compress it a bit. Then again, if I care about image size, I suppose I could always use any standard compression utility on the image. And then I'd want to get decompression going on the TRS-80... Okay, I think it's time to stop babbling. Bill. * I'm _not_ going to make any bad puns about being on the wrong track. :-) On Thu, 1 Jun 2000 13:34:55, Sellam Ismail <foo(a)siconic.com> wrote: ] Current iteration: ] ] Desk Descriptor Header ] ] 1. Host computer type (2 bytes allowing up to 65536 models to be specified) ] 2. Hard/soft sector flag (1 byte) ] 3. Number of tracks (1 byte) ] 4. Disk drive RPM (2 bytes: 1 for whole number, 1 for fraction) [1] ] ] Optional: ] ] 5. Archiver Name (24 bytes) ] 6. Archiver E-mail Address (48 bytes) ] 7. Disk Title (64 bytes) ] 8. Publisher (if applicable) (24 bytes) ] 9. Year of Publication (2 bytes) ] A. Archive Description (256-512 bytes) ] B. Archive Date (4 bytes: 2 bytes = year, 1 byte = month, 1 byte = day) ] C. Archive Time (3 bytes: hour, minute, second) ] ] ***Does it make sense to have separate fields as specified #7-9 or should ] we rely upon the archivist to include that data in the description? I ] think so since this is important information that should be forced to be ] included with the archive. ] ] Maximum size: 685 bytes ] ] [1] If applicable ] ] Note: Encoding type moved to Track Descriptor Header ] ] ] A Track Descriptor Header will precede each track and give an overall ] description of the track: ] ] Track Descriptor Header ] ] 1. Track number (2 bytes: 1 for whole number, 1 for fraction) [1] ] 2. Disk Side (1 byte) ] 3. Track format (logical or raw; host computer specific) (1 byte) [2] ] 4. Track size in bytes (2 bytes) [3] ] 5. Sector format (single-density, double-density, etc) (1 byte) ] 6. Encoding type (1 byte) ] 7. Sectors in this track (1 byte) ] 8. Interleave (1 byte) ] 9. Bytes per sector (2 bytes) ] A. Bits per byte (1 byte) ] B. Offset to next Track Descriptor Header (2 bytes) ] ] Size: 15 bytes ] ] [1] Fraction allows for specifying half- or quarter-track. ] [2] If the track is in "raw" format then fields 3-9 are ignored. ] [3] The total size in bytes of the raw track image. ] ] ] I can start to see where the flexibility afforded by a markup language ] makes sense. I just can't figure out why I am still resisting it though. ] ] So, are we on the right track? The wrong track? ] ] Sellam International Man of Intrigue and Danger ] - ------------------------------------------------------------------------------- ] Looking for a six in a pile of nines... ] ] Coming soon: VCF 4.0! ] VCF East: Planning in Progress ] See http://www.vintage.org for details!

25 years, 11 months

Defining Disk Image Dump Standard

by pete＠dunnington.u-net.com

On Jun 1, 11:10, Sellam Ismail wrote: > On Thu, 1 Jun 2000, Pete Turnbull wrote: > But a lot more volumnious. But this is just my prejudice speaking. Even > though I find HTML useful, I hate it. It needn't be a whole lot more voluminous. The tags should be concise, there's no need to write an essay for each part. Keywords might be a good idea. Tags would be omitted if irrelevant (as many would be for a "raw" archive, or for a common format with no "funnies"). So a disk descriptor might look something like this: {Apple ][<00>soft<00>trks:<40><00>rpm:<15><255><00>{trk:<00><00>logical<00> length:<12><34><00>sectors:<10>{sector:<00><00>{sync{bytes:<16><00>value:<255><00>}{header:GCR<00>trk:<00><00>sec:<00><00>physsec:<00><00>head:<00><00>size:<00><01><00>}{data:< ---256 binary bytes---- >crc:<xx><xx><00>}}sector: [repeat as reqd] }}{track: [repeat as reqd] }} I can't remember some details like the size of a DOS 3.3 track or what the sync bytes are so that's just an stylistic example. The opening "{" marks the start of an object and is matched by a closing "}"; braces are nested because objects are nested. Variable-length strings like "Apple ][" are terminated by some agreed control character (I used ASCII NUL, <00>). Numeric values are stored in binary (actually it might make more sense to store them in ASCII where they follow a string description, but probably not for a block of sector data). So "rpm" is stored as a 2-byte representation of 360. Hmm, we'd need to decide if it's little-endian or big-endian -- or add another tag! > > a problem? The tags don't all need to be ASCII text, things like the > > sector size could be integers, and field lengths could be limited. I'd > > envisage something like nested objects (borrowing from Sellam's slightly > > later mail): > > I don't like the idea of storing the actual sector data as text though. I hadn't meant to imply that; I mean you could hexify it if you wanted, but I don't see any need. Actually one of the things I was thinking of earlier today, was Acorn's "DrawFile" format, which uses similar objects, but the data is still binary (it's a computer program that reads the data, not a human). If a human really did need to read it, you could always use a hex editor. > I guess in this > day and age it doesn't matter much anymore but when I was growing up you > had to make every byte count, and I know more than 95% of us here can > relate to that. Yup, I was too, but I think here the benefits greatly outweigh the disadvantage of extra storage requirement. We want this to be as useful as possible, and the easier it is to use for unexpected formats (to create *and* to read), the more it will get used. > > It also > > means that if the database is lost, damaged, incomplete or otherwise > > inaccesible, an archive can still be understood, and there's no chance of > > inconsistency because two people tried to add new formats at about the same > > time, or someone rolled their own. > > I agree with that. Human readability is definitely a compelling advantage > as is the elimination of the need for a centralized database of system > descriptions. It would still be good to have a central repository. At the very least, it would allow those who know where to look, to see what has already been dealt with, and save a lot of design effort if the format they want is already there. It would be the place to store the explanation of the tag system. Plus, the bigger it gets, the more it will encourage others to archive their treasures, too. -- Pete Peter Turnbull Dept. of Computer Science University of York

25 years, 11 months

Defining Disk Image Dump Standard

by allisonp＠world.std.com

>I also like the inductive matrix ROM used in the HP9100. It works by the >coupling between 512 address tracks and 64 data loops in a 14 layer (?) >PCB. The PCB is about 4" square and stores 512 words, each one 64 bits >long. It is _very_ reliable -- 9100s are now about 30 years old, and >while I've had to replace transistors and diodes in them, I've never >heard of the ROM failing. I Gotta get me one of those, they are so likeable. Allison

25 years, 11 months

Finds

by mcguire＠neurotica.com

On May 31, Zane H. Healy wrote: > Of course since I have a 60Mhz RS/6000 on my desk at work and refuse to > give it up for a state of the art single or dual processor PC my opinions > of acceptable speed might be a little outside the norm :^) > > Remember for most things stability is more important that speed. While I agree 100%, it would seem that the unfortunate proliferation of PeeCees have all but killed that mindset. I suspect that most of us fight very hard to keep it alive. But...on the term "acceptable speed"...isn't that completely subjective? I mean, what's acceptable to you might be too slow for Joe Blow, or uselessly fast for Jane Doe...Intel would have us believe that we all do the exact same thing with our computers, and that the only possible thing that we should find acceptable is *their* brand of high-performance...i.e. blindingly fast until you try to do more than one thing at a time, then it goes into the toilet. Man, if your RS/6000 does the job, and you like it, then keep it, and more power to you! -Dave McGuire

25 years, 11 months

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