test-drb April 1999

test-drb@ccmp.vtda.org

170 participants
1190 discussions

by steverob＠hotoffice.com

> "In programming, it doesn't matter how well it runs or does it's job. The > bottom line is, 'can we sell it to someone?'" Terrible as it seems, that is a cold hard fact. I'm not sure why everyone thinks that MicroSoft's goal is to build good software. Their ONLY goal is to make money! I don't think anyone can dispute their success at doing that. So, how many billionaires has Linux created? Steve Robertson - <steverob(a)hotoffice.com>

25 years, 9 months

Mark-8 Computer - Alive and Ticking!

by jlewczyk＠his.com

Late in Februrary I pulled out of a corner of my workshop a box containing my old Mark-8 computer, the one whose construction was the subject of the cover of Radio Electronics magazine in July 1974. I hadn't looked at in over 22 years! Ah, the memories... When I first read the RE issue, I was in no position financially to purchase anything but the plans ($5 and a SASE, IIRC), being a poor college student (of computer science). It was not until the fall of 1976 that I was able to buy an already constructed Mark-8 from someone who was selling it because he was upgrading (buying a newer microcomputer). I don't know who the original owner was, as the computer was bought by a third party for me. It was astounding to me that I owned my own computer! I proceeded to experiment with it for weeks, hand assembling programs and then keying them in through the front panel! But entering the code through the front panel switches got old real quick, and I endevored to design and build an "octal keyboard and display" for it. The original "backplane" made working on any individual board a real problem: you had to "fan out" the boards to get at the inside ones. So I attempted to make a backplane out of 100-pin wire wrap sockets and bolting edge connectors removed from surplus boards onto the edges of the six Mark-8 circuit boards. After all the work of rewiring the boards with their new edge connectors and wiring the backplane, and then building a new octal front panel board, the computer didn't work at all. (Surprise! ;-) After some time trying to debug it with just a VOM, I abandoned the whole project because I did not have access to the tools (triggered 'scope, logic analyzer, etc.) that I realized I would need to reasonably debug it. Of course there were some great new microcomputers available that were faster and easier to use and program. I bought a KIM-1 and never looked back. Until now. So, I have been attempting to restore the Mark-8 to as close to original condition as possible, which of course includes making it work! ;-). I am pleased to announce that I've been successfull and I'm again the proud owner of a working, .5MHZ computing colossus! I've removed the attempt at a "backplane" and restored it to as close as possible to the origional condition. Originally the computer came with 1K ram, composed of 32 * 256 bit sram chips (Intel 1101A and equivilents). I was dissapointed when I noticed that 1 of the ram chips was missing (I believe it failed, and I threw it out and never replaced it). After getting the system to run with a minimum of 256 bytes, I used memory test routines to check out the remaining memories. I found many more failures, which leaves me with 26 working memory chips. I'm trying to locate more 1101A, so that I'll have enough for 1K and a few spare ones too. Anyone out there have any 1101A or equivilent? (256 bit, pmos, 16 pin package +5V, -9V supply). Another problem I had was a missing 8263 chip (Signetics dual 3-to-1 multiplexor) on the input mux board. I cannot remember why that chip was gone, as the computer certainly wouldn't run at all without it. I probably had removed it to test it, then lost it. I've found that the 8263 chip is impossible to find and have subsequently replaced it with some 74XX chips. I didn't have the data sheet, so I deduced its function by examining the circuit. Only later did I realize that it had inverting outputs, requiring a third chip (a 7404) to complete the replacement circuitry. If anybody out there has an 8263 chip, I'd love to install it an get rid of the replacement circuity. During debugging, I found and replaced three other bad chips, all dealing with the "bus" that I had tried to replace. The other problems were a coupld of solder bridges and various broken connections, especially on the "back plane", which gets flexed every time you fan open the boards in order to access components on them. But the bottom line is.. IT WORKS!!!! And I'm having a great time messing with it. Now what? In the short term, I'm installing the Mark-8 in an appropriate enclosure with a modern switching power supply and fan. I plan on adding an EPROM and UART to it. The EPROM will contain a bootstrap routine for performing a memory check and a "monitor" routine allowing upload from the UART. I want the UART and EPROM to be "vintage" parts (like the AY-3-1013 or COM 2052 UARTs, and 1702A EPROMs. Anyone out there capable of burning a 1702A (or two) for me? I also plan on using a cross-assembler or cross-compiler to write routines for the Mark-8. I'm looking for Intel's PL/M cross compiler and cross-assembler for the 8008. Apparently there also was an 8008 similator. Intel has been suprisingly helpful in reproducing old manuals for the 8008, but the source code for these old tools, THOSE are hard to find. All were written in Fortran, and I understand that Gary Kildall wrote the CP/M compiler. I figure that if I can get the sources, I could port them to the PC. Anybody out there have these old software tools? I also heard that there was a BASIC language for the 8008. Any help with that? Anyone out there have a Mark-8? - John Lewczyk - IO Consulting - 401 Queens Row Street - Herndon, Virginia 20170-3131 - jlewczyk(a)his.com

25 years, 9 months

Parity (was Re: stepping machanism of Apple Disk ][ drive)

by ethan_dicks＠yahoo.com

> On Thu, 8 Apr 1999, Richard Erlacher wrote: > > > My contempt for Apple begins and ends with their total disregard for the > > value of your data. > > They designed the MAC with no memory parity assuming that you'd not mind > > if your data was corrupted without your knowledge... Multiple studies of memory reliability (DRAM) show that parity memory is more prone to failure than non-parity memory. If you want reliability, you have to go to something like Error Correcting Codes (ECC) like the big boys use. We had 39-bit memory on a 32-bit VAX (11/750) because the extra seven bits let you *detect* two faulty bits and *correct* a single bit failure. The Sun Enterprise servers I babysit have ECC memory - we used to get one or two failures in the machine room per year, but they were logged and corrected without any loss of data. My Alpha board (AXP-133 "no-name" board) uses 72-pin *parity* SIMMs in pairs to implement ECC on a 64-bit memory bit. The problem with parity is that yes, you do know that you had a failure, but now you have 9 bits that might fail, not 8, raising your risk by 12%. DRAM failures are more often total rather than intermittent. A memory test at power-up is a better insurance policy than relying on parity to save your butt. I did have the parity circuit on a PeeCee cough up a lung once... it was even a five-slot original PC (256K on M.B.). We were using it into the 90's because it was merely the terminal for a Northwest Instruments logic/CPU analyzer that we used to check for problems in our MC68000-based serial boards. One day, the PC would not come up. Because everything was socketed and because I owned an IC tester, we got a bottom-of-the-totem-pole tech grunt to pull each chip and test it. It was a faulty 4164. Labor costs: $25. Parts cost: $0.60 for a part we stocked thousands of for one of our older products. I still have the machine. It still works. I wish I had the invoice for that CPU; the company bought it new in 1981, around $5K, I know, but I'd like to know the exact figure. Bottom line: Apple not using parity is not a reason to trash the Mac. How many PCs have parity since we moved to EDO and SDRAM? It's extra cost and extra complexity and extra possibilities for failure. Unless you can correct the failure, it's not mathematically worth the extra expense and reduced reliability. -ethan _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

25 years, 9 months

Fwd: Unisys system avail

by sinasohn＠ricochet.net

25 years, 9 months

Floppy and Hard disc questions....

by arfonrg＠texas.net

I have just gotten an old GRiDCase 1530 running and now I need to rig some things. First the harddisc: 1) The manual says that it uses an IBM AT compatible harddisc. What's the difference between an IBM AT style harddisc and an IDE? Is there anyway to rig an adapter? 2) There's a floppy expansion plug on the back but I do not know the signals needed for a generic floppy. Is there a web page with the pinouts, signal directions and a signal description? Thanks, Arfon ---------------------------------------- Tired of Micro$oft??? Move up to a REAL OS... ######__ __ ____ __ __ _ __ # #####/ / / / / __ | / / / / | |/ /## ####/ / / / / / / / / / / / | /### ###/ /__ / / / / / / / /_/ / / |#### ##/____/ /_/ /_/ /_/ /_____/ /_/|_|#### # ###### ("LINUX" for those of you without fixed-width fonts) ---------------------------------------- Be a Slacker! http://www.slackware.com Slackware Mailing List: http://www.digitalslackers.net/linux/list.html

25 years, 9 months

Floppy and Hard disc questions....

by edick＠idcomm.com

see imbedded comments below, please. Dick -----Original Message----- From: Arfon Gryffydd <arfonrg(a)texas.net> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Friday, April 09, 1999 7:59 AM Subject: Floppy and Hard disc questions.... >I have just gotten an old GRiDCase 1530 running and now I need to rig some >things. > >First the harddisc: > >1) The manual says that it uses an IBM AT compatible harddisc. What's the >difference between an IBM AT style harddisc and an IDE? Is there anyway to >rig an adapter? The PC/AT disk drive used the ST-506 interface (20-conductor data cable, 34-conductor control cable) and what was essentially a WD-1002 WAH controller. The IDE interface is, from a software perspective, essentially the same interface as what was used with the WD controller card. The controller hardware has simply been migrated to the drive. Now, EIDE is another bird. It has enhancements which make it less compatible with that old firmware. It's advisable you try your Grid machine with an old disk drive first before you fiddle with the drive adapter hardware. >2) There's a floppy expansion plug on the back but I do not know the >signals needed for a generic floppy. Is there a web page with the pinouts, >signal directions and a signal description? > What you have to find out is what the pinout of that particular connector is. There are lots of sources for standard FDD interface cable pinout. > >Thanks, > >Arfon >---------------------------------------- > Tired of Micro$oft??? > > Move up to a REAL OS... >######__ __ ____ __ __ _ __ # >#####/ / / / / __ | / / / / | |/ /## >####/ / / / / / / / / / / / | /### >###/ /__ / / / / / / / /_/ / / |#### >##/____/ /_/ /_/ /_/ /_____/ /_/|_|#### ># ###### > ("LINUX" for those of you > without fixed-width fonts) >---------------------------------------- >Be a Slacker! http://www.slackware.com > >Slackware Mailing List: >http://www.digitalslackers.net/linux/list.html

25 years, 9 months

microcode, compilers, and supercomputer architecture

by hhacker＠home.com

>> The only deliberately non-deterministic development tool I've ever used was >> a Xilinx FPGA fitter. Somehow it seemed reminiscent of the bogosort >> algorithm. > >Don't get me started on the Xilinx tools. Suffice it to say, I spent >enough time undoing the damage that they did to my designs. I hate >computers that think they can design better than I can. They are almost >always wrong ;-) > >-tony > My point, exactly. It is clearly the case that automated mechanisms are inferior to a quality human intelligence. For anyone to think otherwise is to relegate decisions of life to a computer program. As we all know, or should all know, artificial intelligence falls _way_ short of its lofty goals. William R. Buckley

25 years, 9 months

Parity (was Re: stepping machanism of Apple Disk ][ drive)

by edick＠idcomm.com

Yes, increasing the amount of memory by 1/8 increases the likelihood of failure by 1/8. The inclination to bury one's head and ignore the potential for memory or bus failure comes from the competition for price advantage on the personal computer market, though. The argument I've heard is "if MAC'c can live with it, so can PC's" which may not be true, but appears to be true enough for the typical user. Once such a memory failure is detected, there's nothing you can do about it except endeavor NOT to save the data which may be corrupted and become aware of the problem. I see memory parity errors (most of the PC's here use parity or single bit error correction) about twice a year. Normally it's when a new box is being brought up and memories aren't seated right or something on that order. I don't know what that says about the memory systems of today. It's been a few years, but I always preferred single-bit correction over parity in sizeable memory arrays. I designed one fairly large buffer memory for Honeywell, which had 72-bit-wide memory, 64 MB deep, which was quite a bit for that time (1991) with single bit correction only to have the manager tell me it was not needed. "Whom are we helping with this added expense?" was his position. I pointed out that it would make memory problems a depot or even field repair whereas it would be a return-to-factory otherwise. He insisted, though. The software lead and I agreed we'd base our memory check on parity, which still allowed for isolation of the faulty SIMM. Since this was not a main system memory but just a data buffer, it didn't matter that it ws defective and firmware could rigorously isolate the faulty device. I'm not sure what you're saying about the relative value of the extra bit of memory versus the risk of promulgating a transient error into infinity by recording it as though it were correct, Ethan. You seem to suggest that it would have been better not to have had the 60-cent memory part in place rather than to find and repair it once its failure was detected by parity circuitry. I doubt you believe that, however. It is true that the addition of parity circuitry means that there is an elevated likelihood of failure proportinal to the increased memory size. It is also true that parity checking circuitry requires time to work, and can, itself, fail as well. Increased circuit complexity does increase the statistical probability of failure. ECC circuitry doesn't decrease the probability of memory failure. It does decrease the amount of down-time resulting from it, and it avoids the data loss and down-time associated with single-bit transient failures, which are more common than hard failures. I guess it's like automobile insurance. If you have assets you need to protect, you buy it. If you haven't you don't. My assessment is that Apple started with the assumption that you don't. Dick -----Original Message----- From: Ethan Dicks <ethan_dicks(a)yahoo.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Friday, April 09, 1999 6:10 AM Subject: Parity (was Re: stepping machanism of Apple Disk ][ drive) > > >> On Thu, 8 Apr 1999, Richard Erlacher wrote: >> >> > My contempt for Apple begins and ends with their total disregard for the >> > value of your data. >> > They designed the MAC with no memory parity assuming that you'd not mind >> > if your data was corrupted without your knowledge... > >Multiple studies of memory reliability (DRAM) show that parity memory is >more prone to failure than non-parity memory. If you want reliability, you >have to go to something like Error Correcting Codes (ECC) like the big boys >use. We had 39-bit memory on a 32-bit VAX (11/750) because the extra seven >bits let you *detect* two faulty bits and *correct* a single bit failure. >The Sun Enterprise servers I babysit have ECC memory - we used to get one or >two failures in the machine room per year, but they were logged and corrected >without any loss of data. My Alpha board (AXP-133 "no-name" board) uses 72-pin >*parity* SIMMs in pairs to implement ECC on a 64-bit memory bit. > >The problem with parity is that yes, you do know that you had a failure, but >now you have 9 bits that might fail, not 8, raising your risk by 12%. DRAM >failures are more often total rather than intermittent. A memory test at >power-up is a better insurance policy than relying on parity to save your butt. > >I did have the parity circuit on a PeeCee cough up a lung once... it was even >a five-slot original PC (256K on M.B.). We were using it into the 90's because >it was merely the terminal for a Northwest Instruments logic/CPU analyzer that >we used to check for problems in our MC68000-based serial boards. One day, the >PC would not come up. Because everything was socketed and because I owned an >IC tester, we got a bottom-of-the-totem-pole tech grunt to pull each chip and >test it. It was a faulty 4164. Labor costs: $25. Parts cost: $0.60 for a >part >we stocked thousands of for one of our older products. I still have the >machine. It still works. I wish I had the invoice for that CPU; the company >bought it new in 1981, around $5K, I know, but I'd like to know the exact >figure. > >Bottom line: Apple not using parity is not a reason to trash the Mac. How >many PCs have parity since we moved to EDO and SDRAM? It's extra cost and >extra complexity and extra possibilities for failure. Unless you can correct >the failure, it's not mathematically worth the extra expense and reduced >reliability. > >-ethan > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com >

25 years, 9 months

stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4 floppies)

by edick＠idcomm.com

Careful, now! He would have played hell trying to interleave memory accesses between an 8080 and the video refresh process, since its various cycle types were so different. It would have been worse YET with a Z-80! The 6502 also allowed him to proceed with his own DOS and his OWN version of BASIC, without which he mightn't have gotten the strangle-hold on the personal-computers-in-business market. It's pretty hard to criticize his choices, however little I liked the result from the standpoint of seeing it as a tool, but his (and his partner's) decisions were definitely vindicated in the marketplace. Dick -----Original Message----- From: Ward D. Griffiths III <gram(a)cnct.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Thursday, April 08, 1999 10:34 PM Subject: Re: stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4 floppies) >On Thu, 8 Apr 1999 allisonp(a)world.std.com wrote: > >> Actually there are two points. One is track 000 and the other is the >> innermost (for sa400 35-40 tracks later). Only track 000 was sensored >> save for apple didn't use that either. Apple cut the interface to the >> minimim number of wires and signals possible and made up the difference >> with software, rather clever in my mind. > >During the design phase, Woz had more time than money, chips cost money >and software only cost time. Remember that he _wanted_ to use the 8080 >but the 6502 cost only a tenth the price. (Imagine what the Apple >might have been like with a decent CPU from the start). >-- >Ward Griffiths >"the timid die just like the daring; and if you don't take the plunge then >you'll just take the fall" Michael Longcor >

25 years, 9 months

Rotting away

by ethan_dicks＠yahoo.com

--- Roger Merchberger <zmerch(a)30below.com> wrote: > Once upon a midnight dreary, Ethan Dicks had spoken clearly: > > >Every once in a while, I still go to video-game auctions. It is possible to > >pick up full-sized games for under $100 if you don't want the hottest games. > >PacMac, Galaga and other classics are still available, but for big bucks. > > Where? I'd like to pick up a video game (over 10 years old -- something > like "Time Pilot" or somesuch, so this *is* on topic... ;-), but where I > live nothing like that is available. As I said, in my area, there is a company that has a rolling road show that auctions off games and ordinary people and companies alike can buy and sell. I no longer have the contact info for the auction company since I haven't been to an auction in long enought that they have dropped me from the mailing list. > Also, is there a web (or other) reference as to what games used which > processors? I think several games used the Moto6809, and if I had my > druthers, I'd get a game based on that processor, as it's my favo[u]ite. I would think that some of the arcade emulation sites would have that info as it pertains directly to what you can emulate. I don't have any sort of list, but I can say that Gorf and Wizard 0f Wor use the Z-80 and many Atari games use the 6502. -ethan _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

25 years, 9 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