test-drb April 1999

test-drb@ccmp.vtda.org

170 participants
1190 discussions

by cisin＠xenosoft.com

On Sat, 17 Apr 1999, Ethan Dicks wrote: > . . . > that have read errors that DOS won't get past, bad sectors and the like. For most situations it surely wouldn't matter. But for diskette repair, it would actually help to be more specific on the exact error messages. For example, with a "Parity error", or even "Data error during read", then it may be possible to easily recover a partially correct sector content. But NOT with a "sector not found" error, which can only be fixed by patching up the sector headers. > Are there any tools to go divining on DOS floppies that work better than > an endless succession of "R"etries? It's an all or nothing prospect; the > first disk has the install file, the remaning disks have a chopped monolithic > data file. If one disk can't be read, the whole set is fundamentally useless. > Thanks for any suggestions. The Central Point "Option Board", running the TE (Track Editor) program can be quite useful for such repairs. It will let you view what it thinks are the data bits, and/or what it thinks are the clock bits. By fiddling with them and then writing it back, you may be able to repair the damage, even damage to the sector headers! Another similar tool is Trakcess running on a TRS-80 model 3. Sometimes R-etrying enough times can actually work. If you write a short routine to read the suspect sector with INT13 in a loop, you might eventually get a successful read. -- Fred Cisin cisin(a)xenosoft.com XenoSoft http://www.xenosoft.com 2210 Sixth St. (510) 644-9366 Berkeley, CA 94710-2219

25 years, 8 months

Apple HAL XEBEC controller

by pete＠dunnington.u-net.com

One of today's acquisitions is a small card for an Apple ][ (or Apple ///), labelled "APPLE 2/3 XEBEC INTERFACE REV 1". I happen to have a couple of old Xebec ST412 winchester controllers, so I'd like to try this out. Can anyone tell me the pinout of the 26-pin header at the end of the card? Pins 3,7,11,15,17,19,21,23,25 are grounded, the other seventeen seem to be signal lines. Pins 1,5,9,13,20 are high impedance; the other even-numbered pins are terminated by a 220/330R resistor pack. Does it need any other software (like a formatting disk)? The on-board 4K EPROM contains only the strings "(C) HAL COMPUTERS LTD 1983", "A/XHAL SHARED RESOURCE WINCHESTER SYSTEM", "NOT CONNECTED", and "SRS ERROR", so I guess there would have been a floppy with it, originally. -- Pete Peter Turnbull Dept. of Computer Science University of York

25 years, 8 months

z80 timing... 6502 timing

by edick＠idcomm.com

I've been told, can't prove it, though, that the NEC version of the Z-80 didn't have that "bug" (short for undocumented feature, as in "one man's feature is another man's creature") that in certain instances the flags were incorrectly set by a block load instruction or some such. It's little things like that that can throw folks off. That, actually, is why I favor a simulator. I've just never seen a proper simulator for either processor in an "open" environment, i.e. where only the processor is simulated. That makes it entirely hardware independent. Some folks would believe, however, that since it's not possible to build a system that's hardware independent, it's not valid to simulate one. Do we really want to build hardware for the sake of this comparison? Writing a bare-bones simulator would be straightforward enough. It's really just a big switch statement. The beauty is that you can include/exclude undocumented features as you see fit. The gotcha is that it's easy to go down a road which has no relevance to reality, i.e. if the processor doesn't work like that, even though it should, then simulating it like that is not valid. Dick -----Original Message----- From: Allison J Parent <allisonp(a)world.std.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Saturday, April 17, 1999 9:20 AM Subject: Re: z80 timing... 6502 timing ><65C02, because it was buillt in several conflicting versions. What about ><the Z-80 core? Whose? Which one? Speed, of course, should be "limited" t ><whatever was available in 1982. That certainly includes the Synertek (MOS > >In 1982 all of the z80s in the market had the same hidden features >including the IX/IY 8bit ops. I know of no z80 that didn't have them. >Not all of them were available to the 6mhz spec though many could be >pushed. Also allowed is the 8085 (available as a 5-6mhz part then). Again >all of the 8085s had the extra unsupported instructions as they were deem >important! > >Allison >

25 years, 8 months

z80 timing... 6502 timing

by edick＠idcomm.com

about those undocumented opcodes . . . I didn't pursue what happened to them in the UMC, VLSI, SYNERTEK, Mitsubishi, or WDC (WSI) parts. I heard rumors, but wasn't concerned about it then. After 1982 I only used the ROCKWELL CMOS parts. Rockwell took care of them by getting rid of them. Of course they expanded the instruction set as did several others. Dick -----Original Message----- From: Allison J Parent <allisonp(a)world.std.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Saturday, April 17, 1999 1:42 PM Subject: Re: z80 timing... 6502 timing >The 6502 series had all sorts of undocumented opcodes and they tended to >change with later versions. Rockwell made a specific point about the undocumented opcodes in their version, in that all the unimplemented opcode values in their CMOS parts were NO-OP's. ><THe 65xx stuff is quite known, but what has been new to my ears are the ><8085 'hidden' operations. > >Those were more useful as the 8085 had some rather open holes in the >instruction set. The z80 also had a raft of them all commonly supported >though officially unofficial. and none were compatable with the 8085 hidden >ops (in either direction). > >Allison >

25 years, 8 months

z80 timing... 6502 timing

by allisonp＠world.std.com

<The one I routinely hear about the Z-80 is one which places the odd parity <of the bytes (or maybe the lsb's of the bytes) in a block moved with an LDI <or INIR instruction into the carry or some such. This instruction is <supposed to leave carry unaffected, but doesn't. If it did it never happens to me and ouls severly break code. The block moves and compares are widely used in z80s. The only flag affected is the P/V and that is documented BC-1=0. The z80 does have a difference from the 8080 for some operation regarding the parity/overflow flag.

25 years, 8 months

z80 timing... 6502 timing

by allisonp＠world.std.com

<I've been told, can't prove it, though, that the NEC version of the Z-80 <didn't have that "bug" (short for undocumented feature, as in "one man's <feature is another man's creature") that in certain instances the flags wer Did not have that "bug". I don't know that any z80 had it. It was exact. What was missing was a odd address bus burp during t3-t4 transistion. If your design compensated for it the NEC part didn't hurt you and if you didn't It might help. Now the z180 between zilog and hitachi had bugs. The Z280 was buggy too. Allison

25 years, 8 months

z80 timing... 6502 timing

by allisonp＠world.std.com

<b) unsupported OPCs in the 8085 ? Did I miss them ? I did 2 years of <8085 development projects, and never heared of (also of course never <used) - can you tell what they where alike ? Yes, They are somewhat handy. 08h DSB double subtract HL-BC->HL 10h SHRL shift right HL Shift HL pair right, MSB is copied 10001000:00000010 becomes 11000100:00000001 18h RDEL Rotate DE right through carry, handy 16bit rotate. SLDE (intel used this neumonic) 28h LRI h,D8 load relative pointer immediate The value of HL is added with the immediate placed in the DE pair. 38h LRI SP,D8 similar to the previous, good for SP relative ops. D9h SHLX Store HL at DE an indexed 16bit store. EDh LHLX Load HL from where DE points. 16 bit indexed load. This is from memory... so if there are errors let me know, I'll dig out the docs. I do remember that NEC up to at least '85 actively supported these as they were in the intel, OKI and AMD designs. Allison

25 years, 8 months

*.cam files

by roblwill＠usaor.net

Thanks! I should have the pictures up and my web page updated by the end of the week! -- -Jason Willgruber (roblwill(a)usaor.net) ICQ#: 1730318 <http://members.tripod.com/general_1> -----Original Message----- From: Michael Passer <mwp(a)acm.org> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Saturday, April 17, 1999 6:00 AM Subject: Re: *.cam files >If those files are from a Casio QV digital camera, a program to convert >them to the JPG format is available at > >ftp://ftp.itojun.org/pub/digi-cam/QV10/ > >There are both Unix and Windows versions available. I tested the >Windows version and it's straightforward and works. > >Hope this helps! > >--Michael Passer >mwp(a)acm.org > > >----- Original Message ----- >From: Jason Willgruber <roblwill(a)usaor.net> >To: Discussion re-collecting of classic computers ><classiccmp(a)u.washington.edu> >Sent: Saturday, April 17, 1999 12:33 AM >Subject: *.cam files > > >> Hi! >> >> I was just given some *.cam files. They're supposed to be image files >of a >> computer to put on my webpage (classic computer section). They were >taken >> with a digital camera, and downloaded to a PC. My question is: how >in the >> heck do I view them?? Anyone have any idea? >> -- >> -Jason Willgruber >> (roblwill(a)usaor.net) >> ICQ#: 1730318 >> <http://members.tripod.com/general_1> >> >> > >

25 years, 8 months

x86, x86 everywhere, but... (was OT: Re: Time to declare State of MA)

by yakowenk＠cs.unc.edu

I am slowly coming to accept that my value set was molded when certain things were scarce, and no longer are. I would have been thrilled to get any kind of computer when I was in high school. So it is hard for me to imagine people willing to throw away _any_ computer. But now I am starting to see that XT's and 286's are like paper cups. Not only do they tend to work less well as they age (they eventually break and lack support from their manufacturers), but they are really next to valueless in terms of replacement cost. Even if getting a computer to somebody who is destitute, the time of the compu-geek who sets it up is worth more than a newer faster machine would be. The only difference between the old x86 machines and paper cups is quantity: there are fewer paper cups. Bill. (I'm not advocating a throw-away culture, BTW. Just noting the economics of the situation. I wish we could convince people to put in the effort to use and learn from the old machines rather than continuously filling up landfills with them just to make more. But I'm still a long way from getting the rest of the world to see things my way.) (Okay, so that's another difference between XTs and paper cups: paper cups are more landfill-friendly.) On 15 Apr 1999, Mike Ford <mikeford(a)netwiz.net> wrote: ] The Goodwill near me just got 600 computers from Pacific Bell, all 486 and ] older, most in pretty good shape. The result is that a LOT more only ] slightly wanky 486 boxes are getting tossed in the scrappers bin. Goodwill ] won't take a 386, or if it gets in the product stream it goes either to the ] scrapper or the huge AS-IS morning auction of bins of stuff only loosely ] sorted by category. ] ] However painfull you may find it personally, it only takes a TINY bit wrong ] to make an old computer have negative value except as scrap or parts.

25 years, 8 months

OT: Welfare state morality

by allisonp＠world.std.com

<is simply that these computers aren't new enough. They can be used for <anything that a new one can be used for, but they won't read the newest MS BZZT. i'm running a PS/250z with a scanner and I can and do. <Word files. Microsoft made sure of that. Believe it or not, people can be Simple dont use word, it's virus prone. <very picky about such things. Also, there is the issue that the computer <will never be used, or will get thrown away the next day, whatever. The <point is that there is no justification for the trouble it takes to <distribute computers to individuals. If these individuals want to get a <computer, fine. I have found dozens of computers in garbage cans, I'm sure <they can do no worse. There is a lot of truth to that. I think it's more the matter of where Max is a decent 386 is trash fodder but in may parts of this country (USA!) that would be a windfall. After a day of trying to make billies OS and code work, killing a gutted clone sounds like a great release of stress. ;) Allison

25 years, 8 months

Jump to page:

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 April 1999