test-drb August 2004

test-drb@ccmp.vtda.org

283 participants
661 discussions

by blair＠averagebacon.com

Just thought folks might be interested in this one: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=5115163292&ssPageNa… Blair

22 years

Brother Wordprocessor Floppy Disks

by T.Baillie＠mcauley.acu.edu.au

Hi I saw in a forum your discusion about reading Brother wordprocessor floppy disks and am in the same situation, could you forward the tool spoen about on the forum please? does the software only convert the file, or does it allow you to read the disk on a pc? thanks Tim Don Maslin donm at cts.com Wed Mar 3 16:05:07 CST 2004 Previous message: Brother Wordprocessor Floppy Disks Next message: Brother Wordprocessor Floppy Disks Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] On Wed, 3 Mar 2004, tim lindner wrote: > Yesterday my boss came to me and handed me a stack of 3 1/2 inch floppy > disks and asked me to get the data off them. > > Ahh, the perils of being the geekiest person in your orginazation! :) > > Anyway, all he could tell me is that they were from a Brother word > processor. It didn't have a model number and no serial port. > > One of the disks is a system disk ("Spreadsheet, punctualtion alert and > data storage disk for Brother Word Processor version <1.0>") and is > dated 1991. > > I tried the disk in my DOS 6.22 PC, no deal. > > Then I tried cw2dmk (thanks Tim!) and my Catweasel, but I guess the > format isn't close enough to IBM 370 (FM) or IBM 34 (MFM) formats to be > useful. > > Does anyone know of a tool I can use to read these disks? Tim, the attached ZIP contains software that was sent to me a while back which is supposed to convert Brother Word Processor stuff to other - perhaps, more common - WP formats. I have not had occasion to try it, so will be interested in your experience. It will not make it to the list, of course, thanks to the attachment 'scraper'. - don > Barring that: does anybody know what format the disk is using? I'm not > past modifying cw2dmk to read it, but I would hope not to have to > reverse engineer the "on disk" format. > > Thanks! > > -- > tim lindner > tlindner at ix.netcom.com > Timothy Baillie ACUweb Online Education, ACU National T +61 7 3623 7425 F +61 7 3623 7193 PO Box 456 Virginia Qld 4014, Australia http://www.acuweb.com.au/

22 years

PET startup sequence?? (was LF: Commodore PET schematics, troubleshooting info)

by dwight.elvey＠amd.com

>From: "Pete Turnbull" <pete(a)dunnington.u-net.com> > >On Aug 13 2004, 11:27, Dwight K. Elvey wrote: > >> You should try to create a more exhaustive RAM test. >> Although, time consuming, GALPAT is just about the >> most intensive. > >I know Dave doesn't need it now, but a GALPAT is a very slow test for >any sizeable amount of RAM. It's also very old, and not 100% effective >against certain errors, though much better than some of the common >march tests. Hi There are many kinds of test. The simplest effective test for stuck-at and address problems is the March C. It lacks many possible problems that are not simple stuck at. Worst case column test require various types of walks ( GALPAT is one of these ). Still, most simple RAM test Used by POSTs will do about as well as a March C. Now we get into some of the other problems of address line switching, retention and pattern problems. One need not include the entire memory in there GALPAT test. One can work in blocks and then work on a block to block sampling. It is a long test but then it does a lot of things that take a long time. I only suggested it because it seemed that he had an issue that a simple RAM test wasn't showing. I am involved with creating BIST engines for use on arrays in uP's I would never put a GALPAT in a production test but if I can get two address generators, it is easy to implement as a programmable element. It, along with other test, can often be used for diagnostic operations to help understand a fault until a simpler/quicker test can be used to detect that particular fault. Dwight

22 years

RAM test: was Re: PET startup sequence??

by pete＠dunnington.u-net.com

On Aug 14 2004, 11:11, Vintage Computer Festival wrote: > On Sat, 14 Aug 2004, Pete Turnbull wrote: > > > registers), though it would on a 6502. If anyone wants a copy I can > > give you the Z80 code, some notes from the project writeup, and the > > CACM references. > > Please! OK, it's below. First I ought to explain a couple of things about the code and the system it was written for. This was for a very basic Z80 system consisting of some EPROM, RAM, timers, and minimal I/O, which included a 2-line x 16-char LCD display. It was used for second-year project work. The way the LCD display was interfaced precluded the use of normal hanshaking or reading, so the routines that write to it incorporate a delay long enough to ensure that the display has completed the update before another write can occur. Secondly, the whole system was designed to report any error (and refuse to continue if it was serious), and to do this, the startup routines perform a number of tests, each of which uses no part of the hardware that's not already been passed "good". Well, that's the ideal; it's not so simple in practice. It begins with a ROM CRC check (and it's a proper CRC, not a simple checksum, so it will catch all single-bit errors, most 2-bit errors, and many multiple-bit errors). It should really do a CPU test first, but that would need the ROM to hold the test routines. The justification here is that it uses nothing except the processor and the ROM itself, and the assumption is that any serious fault in the processor will cause that to fail. If so, it's easy to take out the ROM, CRC check it on an EPROM programmer, and tell whether the ROM really is at fault -- if not, it must be the CPU. The chances of a CPU failing are quite small; the chances that a failing CPU will still execute instructions are a fraction of that; the chances that a CPU with faulty instructions will still execute the CRC test are a fraction of that; the chances that a faulty CPU that still passes the CRC has faults in common instructions used elsewhere are ... etc. So at the point that the RAM test executes, we "know" the CPU is OK and we know the ROM is OK, but we don't want to use the RAM to hold data during the RAM test. So no variables other than in registers, and *no stack* hence no subroutines. Hence the rather odd way of executing pseudo-subroutines to display things (on the LCD which we assume is working; it's just been "exhaustively tested" by the visual test of seeing a "ROM CRC ERROR" or "ROM CRC PASSED" message, followed by "RAM test" on it :-)). Lastly, this test does everything one bit at a time, not one byte at a time. That's because the system used byte-wide RAM, in which in theory any bit could interact with any other. You could safely parallelise this to do a byte at a time if you used a separate RAM chip for each bit (because you could assume they wouldn't interact except through a faulty data bus or power glitches) and that would speed it up more than 8 times. Here's the code: # Filename: RAMtest.s # # Author: Pete Turnbull # Address: Department of Computer Science, University of York, # Heslington, YORK YO10 5DD. # Email: pnt1(a)york.ac.uk # # Created: 26-Nov-1995 # Last update: 18-Nov-1996 # Description: An efficient RAM test # Version: 0.4 now uses 20-bit error-counter # 0.3 modified to work as standalone test for CTS 19-Oct-1996 # 0.2 code converted from ZASM to as80 for MCP, March 1996 # 0.1 original module for inclusion in CTS 1995, coded in ZASM # # ************************************************************************** # * # * An implementation of Suk and Reddy's Test B RAM testing procedure. # * Implemented from information in an article "Functional Testing of # * Semiconductor Random Access Memories", M.S.Abadir and H.K.Reghbati, # * Computing Surveys, Vol.15 No.3 September 1983, ACM. # * The original NTA article is "Efficient Algorithms for testing # * Semiconductor Random Access Memories", Nair, Thatte and Abraham, IEEE # * Transactions on Computing, Vol.C-27, No.6, June 1978. # * A similar fault model was used by D.S.Suk and S.M.Reddy, to develop even # * better tests, including their Test B, described in "A march test for # * functional faults in semiconductor random access memories", IEEE # * Transactions on Computing, Vol.C-30, No.12, Dec 1981. # * This is an O(n) procedure, much more efficient for large memories than # * GALPAT. It also finds coupling faults invisible to GALPAT tests. # * # * GALPAT complexity 4n^2 + 2n, finds all stuck-at, and some coupling faults # * GALPAT-II 4n^2 + 4n, finds all stuck-at, and all coupling faults # * T&A 8n.lg(n), finds all stuck-at, and all coupling faults # * NTA 30n, finds all stuck-at, and all coupling faults # * S&R-B 16n, finds all stuck-at, and all coupling faults # * assuming no decoder multiple-access faults, # * and all decoder faults if no coupling faults. # * # * The proviso about coupling/decoder faults really just means that the two # * types of fault are seen as equivalent (indistinguishable) by the test, # * not that they are not detected. # * # * There are even faster tests than S&R-B but they don't necessarily find # * all errors (some errors may mask others). # * With our Z80 running at 3.6864MHz, this test takes about 6 seconds. # * From the formulae above, an "equivalent" GALPAT would take over an hour. # * # * Byte operations would be acceptable for 1-bit wide memories, merely # * being an application of parallel testing. However, our RAM is 8-bit, so # * we use multiple operations to access each bit in a byte. This is not # * quite according to the test specification, as the lower bits in each # * byte are read/written up to 21 more times than they should be. # * However, if the RAM is OK, correct values are written every time, and # * consideration of the fault model shows that this will only affect soft # * errors, which, by definition, are likely to be corrected by other # * operations in the test procedure and would not be detected by most test # * algorithms. # * If we just used byte operations, we might miss some coupling faults. # * # * Errors are reported on the LCD, using in-line code (no subroutine stack), # * in the form "aaaa:xx (yy) -pp" where "aaaa" is the address with the error, # * "xx" is the found data, "yy" is the expected data, and "pp" is the section # * number (1A, 1B, 1C, 2, 3 or 4). DE holds an error count, supplemented by # * H to use 20 bits so that multiples of 8*8192 errors (eg every bit in every # * byte of 8K) can be recorded. # * # * The test always runs to completion, but then displays the error count and # * HALTs if it's non-zero. If it is zero, this version prints the message # * "RAM OK " and halts. # * # ************************************************************************** # # # ***** Memory addresses ***** # rom = 0 # start of 8KB EPROM area romtop = 0x1FFF # last byte in ROM ram = 0x4000 # start of 8KB RAM area ramsize = 8192 # size of RAM ramtop = ram+ramsize-1 # last address in RAM # # # ***** I/O addresses ***** # LCDins = 0x80 # LCD base address, instruction register LCDdat = LCDins+1 # LCD data register # # # ***** assorted constants ***** # LCinit = 0x3C # LCD "Funct.Set": 8 bit data, 2 lines LCDoff = 0x08 # set off: OR this with D/C/B for ON Don = 4 # sets Display ON LCDon = LCDoff + Don # set on: OR this with C/B for cursor Con = 2 # sets Cursor ON Bon = 1 # sets Blink ON (else cursor is solid) LCDclr = 0x01 # clears LCD display/RAM, sets address 0 LCDhom = 0x02 # moves cursor to position 1, line 1 setCG = 0x40 # sets "write to char gen RAM". OR with addr. setDD = 0x80 # sets "write to data display". OR with addr. line2 = 0x40 # address of second line setL2 = setDD + line2 # sets "write" to write to line 2 # dly120 = 32 # loop constant for just under 120 microsecs space = ' ' # ASCII space character # # # ************************************************************************** # * # * Here is the actual code... # * Note there's no point in pushing registers or calling subroutines, # * as we're scribbling all over all the RAM including the stack area. # * Before we start, reset LCD and tell the world what we're going to do. # * # ************************************************************************** # .org rom init: ld a, LCinit # tell it about data format etc out (LCDins), a ld b, dly120 waitI0: djnz waitI0 # let the LCD sort itself out ld a, LCDclr # clear display and RAM, home cursor out (LCDins), a ld bc, 4900/7 # that takes about 4.9ms waitLC: dec bc # loop takes 26 T-cycles, about 7 microsecs ld a, b or c jr nz, waitLC # wait for init to complete ld a, LCDon + Con # turn on the display out (LCDins), a ld b, dly120 waitI1: djnz waitI1 # let the LCD get it done ld hl, SRBmsg jp mssgHL # and return from there to following code SRBmsg: "RAM test " # this message fills the first line .byte 0 # terminator # # # ***** Step 0. Initialise, and set all RAM to 0's (we hope). # 8Kbytes-worth of LDIR takes 21 T-cycles x 8192, about 47 milliseconds # SRB0: ld de, 0 # assume we're going to pass - no errors ld h, d # (error counter is 24-bit) exx # save that thought! ld hl, ram ld (hl), 0 # set first location to zero ld bc, ramsize - 1 # make 1FFF copies... ld de, ram + 1 # ...starting here ldir # block copy, fastest way to set all the rest # # ***** Step 1. 3 pairs of read/write operations for each *bit* (not byte). # This is a marching pattern, but tests that each bit can be 1 or 0. # For sake of speed, loops are done with JP, faster than JR if jump # is made. However, JR is faster if the jump is not taken, so is used for # the jump-on-failure -- which hopefully is rarely taken! # "nxtbit" loop takes 110 T-cycles, about 30 microseconds. # "nxtbyt" loop takes 8 nxtbits + 60 T-cycles = 940 T-cycles, about 255us # 8Kbytes-worth takes 255us x 8192 = 2.09 seconds. # ld bc, ramtop + 1 # where to stop ld d, 1 # mask for current bit in current byte ld hl, ram-ramtop-1 nxtbyt: add hl, bc # start position ld e, 0 # what the whole of the current byte should be nxtbit: ld a, (hl) # ** Read: Ci(=0) and d # select current bit jr nz, fail1a # if not still 0, it's duff OK1a: ld a, e # what it should be, so far or d # ** Write: Ci <-- 1 ld (hl), a # put it away ld a, (hl) # ** Read: Ci(=1) and d jr z, fail1b OK1b: ld a, e # current bit is still zero in E ld (hl), a # ** Write: Ci <-- 0 ld a, (hl) # ** Read: Ci(=0) and d # select current bit again jr nz, fail1c # if not still 0, it's duff OK1c: ld a, e # what it should be, so far or d # ** Write: Ci <-- 1 ld e, a # update the copy ld (hl), a # put it to bed rlc d # next bit - NB 8-bit rotate jp nc, nxtbit inc hl ccf # it was set by the last RLC D sbc hl, bc # see if we've run out of RAM jp nz, nxtbyt # # ***** Step 2. Check each bit Ci(=1), then toggle it twice. # "nxtbi2" loop takes 62 T-cycles, about 17 microseconds. # "nxtby2" loop takes 8 nxtbits + 46 T-cycles = 542 T-cycles, about 147us # 8Kbytes-worth takes 147us x 8192 = 1.2 seconds. # ld hl, ram-ramtop-1 nxtby2: add hl, bc # E is still FF, this section doesn't change it nxtbi2: ld a, (hl) # ** Read: Ci(=1) and d jr z, fail2 OK2: ld a, e # what it should be (0FFH) xor d # make current bit zero ld (hl), a # ** Write Ci <-- 0 ld a, e # restore the '1' ld (hl), a # ** Write Ci <-- 1 rlc d jp nc, nxtbi2 inc hl ccf # it was set sbc hl, bc # see if we've run out of RAM jp nz, nxtby2 # # ***** Step 3. Check each bit Ci(=1), then toggle it three times. # "nxtbi3" loop takes 77 T-cycles, about 21 microseconds. # "nxtby3" loop takes 8 nxtbits + 46 T-cycles = 662 T-cycles, about 180us # 8Kbytes-worth takes 180us x 8192 = 1.5 seconds. # ld hl, ram-ramtop-1 nxtby3: add hl, bc ld e, 0xFF # it gets changed to 0 as we go round nxtbi3: ld a, (hl) # ** Read: Ci(=1) and d jr z, fail3 OK3: ld a, e # what the byte should be xor d # make current bit zero ld (hl), a # ** Write Ci <-- 0 ld a, e # restore the '1' ld (hl), a # ** Write Ci <-- 1 xor d # make current bit zero ld e, a # copy it ld (hl), a # ** Write Ci <-- 0 rlc d jp nc, nxtbi3 inc hl ccf # it was set sbc hl, bc # see if we've run out of RAM jp nz, nxtby3 # # ***** Step 4. Check each bit Ci(=0), then toggle it twice. # "nxtbi4" loop takes 62 T-cycles, about 17 microseconds. # "nxtby4" loop takes 8 nxtbits + 46 T-cycles = 542 T-cycles, about 147us # 8Kbytes-worth takes 147us x 8192 = 1.2 seconds. # ld hl, ram-ramtop-1 nxtby4: add hl, bc # E is now zero, after finishing Step 3 nxtbi4: ld a, (hl) # ** Read: Ci(=0) and d jr nz, fail4 OK4: ld a, e # what it should be (00H) xor d # make current bit a '1' ld (hl), a # ** Write Ci <-- 1 ld a, e # restore the '0' ld (hl), a # ** Write Ci <-- 0 rlc d jp nc, nxtbi4 inc hl ccf # it was set sbc hl, bc # see if we've run out of RAM jp nz, nxtby4 jp SRBend # testing completed # # # ************************************************************************** # * # * The following code uses IX to store the return address. It uses BC, # * but restores BC = ramtop + 1 on exit. It prints a message to give # * the failed address, data as read, expected data, and section where # * the error was detected. # * # ************************************************************************** # fail1a: ld ix, OK1a # here if Read: Ci(=0) failed in Step 1a ld a, 0x1A # section code jr fail fail1b: ld ix, OK1b # here if Read: Ci(=1) failed in Step 1b ld a, 0x1B jr fail fail1c: ld ix, OK1c # here if Read: Ci(=0) failed in Step 1c ld a, 0x1C jr fail fail2: ld ix, OK2 # here if Read: Ci(=0) failed in Step 2 ld a, 2 jr fail fail3: ld ix, OK3 # here if Read: Ci(=1) failed in Step 3 ld a, 3 jr fail fail4: ld ix, OK4 # here if Read: Ci(=0) failed in Step 4 ld a, 4 # # ***** This is the part that actually does the printing # fail: ex af, af # save section code for the moment ld a, setL2 out (LCDins), a # address LCD second line ld b, dly120 fwait1: djnz fwait1 # give it time to do its stuff ld c, h # upper byte of failing address ld iy, f.L jr f.hex # print it f.L: ld c, l # lower byte of failing address ld iy, f.coln jr f.hex f.coln: ld a, ':' # print colon out (LCDdat), a ld b, dly120 fwait2: djnz fwait2 ld c, (hl) # get the duff data ld iy, f.spc jr f.hex f.spc: ld a, space # print space out (LCDdat), a ld b, dly120 fwait3: djnz fwait3 ld a, '(' # print left bracket out (LCDdat), a ld b, dly120 fwait4: djnz fwait4 ld c, e # expected data ld iy, f.brk jr f.hex f.brk: ld a, ')' # print right bracket out (LCDdat), a ld b, dly120 fwait5: djnz fwait5 ld a, space # print space out (LCDdat), a ld b, dly120 fwait6: djnz fwait6 ld a, '-' # print a dash out (LCDdat), a ld b, dly120 fwait7: djnz fwait7 ex af, af # where we saved the section number ld c, a ld iy, f.fin jr f.hex f.fin: exx # remember H,DE' had zero to signify "pass" inc e # so update error count jr nz, f.exx inc d # update middle byte too, if necessary jr nz, f.exx inc h # update top byte if necessary f.exx: exx ld bc, ramtop + 1 # caller expects this to be here jp (ix) # back to "caller" (or wherever!) # # # ************************************************************************** # * # * This pseudo-subroutine is "called" to print a pair of hex digits. # * # * Entry: value in C, return address in IY. # * Exit: A and B mangled. # * # ************************************************************************** # f.hex: ld a, c # get value to print rrca # move upper nibble to lower rrca rrca rrca and 0x0F # remove any garbage cp 0x0A # do we need a letter? jr c, AOK.1 add a, 'A' - 0x3A # yes, adjust it AOK.1: add a, '0' # make it ASCII out (LCDdat), a # print it ld b, dly120 Await1: djnz Await1 # give LCD time to do his stuff f.hex1: ld a, c # get lower nibble this time and 0x0F cp 0x0A jr c, AOK.2 add a, 'A' - 0x3A AOK.2: add a, '0' out (LCDdat), a ld b, dly120 Await2: djnz Await2 jp (iy) # return to wherever caller specified # # ************************************************************************** # * # * This pseudo-subroutine prints a message (if the as-yet-untested LCD is # * working) -- for use by the test routines that have no stack. # * # * Place the required message immediately after the call; this code returns # * to the address immediately beyond the message. # * # * Entry: HL points to the message, zero-terminated # * Exit: A, B mangled, HL updated # * # ************************************************************************** # mssgHL: ld a, (hl) # get the character or a # is it the terminator? inc hl # doesn't affect the flags... jr nz, do.mhl # ...so this depends on the character jp (hl) # to the code following the message do.mhl: out (LCDdat), a # send character to LCD ld b, dly120 waitm: djnz waitm # wait for our slow LCD jr mssgHL # repeat until cooked # # # ************************************************************************** # * # * Arrive here on completion of RAM testing # * # ************************************************************************** # SRBend: ld a, setDD + 4 # to replace "test" on LCD with count out (LCDins), a ld b, dly120 fwait8: djnz fwait8 # give LCD time to do his stuff exx # alternate reg set had DE = error count ld a, h # ...see if it passed or d or e jp nz, SRBerr # skip if errors ld hl, SRB.OK # tell the user all is well jp mssgHL SRB.OK: "OK " .byte 0 # marks end of message halt # we're all done here # # ***** do this if RAM failed test # SRBerr: ld c, h # error count, MSByte ld iy, SRBE.M jr f.hex1 # only show 5 digits, to fit 16-char display SRBE.M: ld c, d # error count, middle byte ld iy, SRBE.L jr f.hex SRBE.L: ld c, e # error count, LSByte ld iy, SRB.em jr f.hex SRB.em: ld hl, errors # message " errors" jp mssgHL errors: " errors" # with 20-bit count, just fits 16-char display .byte 0 # marks end of message SRBhlt: halt # unwise to carry on with duff RAM -- Pete Peter Turnbull Network Manager University of York

22 years

Help with IBM 5100 - ROS error

by dave04a＠dunfield.com

Hi Guys, Now that the SuperPET's are off the bench, I have moved on the 5100. This is an IBM 5100, BASIC only, 16K model - I received it about a week ago. It was reported working the last time it was powered up (I have a picture of it taken then with a BASIC program on the screen), however it has been stored in an attic for quite a few years since then. The machine runs, however the "BRING UP" program is reporting an error in the non-executable ROS content and CRC test. At least thats which I understand from the maintenance manual. It gets as far as the 'I' test, then lights the PROGRESS-CHECK light. The screen displays: -------------------------------------------- ABCDEFGHI 18 07 (Bottom line of display) A B C B ~ N_ 13 EZEP (Z and P are underlined) -------------------------------------------- According to the maintenance manual, line 1 cols 1 and 2 should contain the ID of the module it is looking for (18) and 5 and 7 contain an error code (07). I have not been able to determine what '07' means ... Perhaps its in the manual, but I have not found it yet. (Please bear with me, I haven't seen a real live 5100 in aver 20 years, and I have never worked on one before). I have tried removing and reseating all the cards (which is very unplesant as the rubber/foam which supports then when they are in their normal "upside down" position is about the consistance of tar on the surface, which has glued itself to the faceplates of all the cards - I'll be looking for a good way to replace this eventually). Anyone have any experience with reports of bad ROS - is there any other cause (power supply tolerance etc.). I know this is a long shot, but anyone have a unused 5100 ROS? (perhaps >from an APL upgrade or a dead machine) ... (I'd really like to find a full APL ROS :-) Anyone have the code? Anyone ever tried making a substitute? According to the manual, you can get into the level 1 diagnostic mode by pressing either: Cmd * - or possibly - Cmd + / Cmd - / Cmd * Page 3-10 indicates just 'Cmd *' while page 3-15 indicates the longer sequence - neither does anything on my unit - am I doing it wrong, or is this a function in the non-executable ROS, which is not being allowed due to the error? (Does it even recognize this sequence when in the process-check state, as according to the register displays it appears to be halted?) Any help / insight would be greatly appreciated! Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html

22 years

Heathkit EPROM programmer 8401

by depfoto＠earthlink.net

To whom it may concern, I was searching google.com for information relating to my old Heathkit 8401 and stumbled upon your message from almost a year ago. Do you still need to contact someone that owns this device? If so, feel free to drop me a return e-mail.

22 years

Quotations From Chairman Morrow

by vcf＠siconic.com

I located and transcribed a copy of "Quotations from Chairman Morrow", a collection of things that George Morrow of Morrow Designs said over the years he was in the computer business, for Fred. Morrow died earlier this year of cancer. He had been out of computers entirely and was into collecting LPs. He was a good guy. I'm posting this here because there are some gems in there, and some stuff is still relevant. It's also an interesting take on the 1980s microcomputer business. This text is hard to find, so posting it here will make it easier to find for people and hopefully preserve it. I typed it in basically as it was typeset. Numbers preceding each section are actual page numbers in the original booklet. I'm pretty sure I got all the typos, but if you find one please let me know. Enjoy! COMPUTER USERS OF THE WORLD UNITE! QUOTATIONS FROM CHAIRMAN MORROW MORROW DESIGNS PRESS, SAN LEANDRO, CALIFORNIA First Edition: November 1984 Copyright (C) 1984 by Morrow Designs Inc. All rights reserved. No part of this publication can be reproduced without prior written permission of Morrow Designs Inc. Individual quotations can be used at any time with standard attribution. Quotations By GEORGE MORROW Introduction By JOHN C. DVORAK (Portrait of George Morrow) Introduction Morrow: Mayo to Mao It started when George Morrow was a young fry-cook. He had a spoonful of mayonnaise in one hand and a piece of bread in the other. "Hey, I can't do this all my life. Besides the fact that I can't tell good food from bad, this job is boring. I'm going to be an engineer," he thought to himself. So young George pursued the life of an intellectual. For awhile he took engineering, but he figured that to fully understand engineering he needed to know physics. He changed his major to physics. Soon he figured that to fully understand physics he needed to know mathematics. He changed his major to math. Just as he was about to get his PhD in math, he figured that to fully understand mathematics he needed to know philosophy. So he quit and went to work in the semiconductor business. "Otherwise, I would have never gotten out of school," he recalls. Working for William Shockley gave George more insight into philosophy than any college curriculum. It must have. George Morrow has become the top philosopher in microcomputerdom. If you're in the newspaper business, George is the guy to call when you need a quote. Some time back, Adam Osborne was the most quotable, with guys like Seymour Rubinstein and a few others occasionally coming up with a zinger or two. But over the years, Morrow has outdistanced them all. Enough to fill a book--a little red book. I recommend you take this little red book and hunt down George and make him autograph it. It's an obvious collector's item, and it will probably be worth a fortune someday. When you corner George for the autograph ask him about his sugar to gross national product theory. He's convinced there's a direct relationship between sugar consumption and gross national product. George is a little embarrassed by this book, I'm told (by George himself). His public relations firm in cahoots with the staff made him agree to it. You see, George is an interesting guy and these quotes are great, but George thinks it detracts from the great equipment that the company manufactures. You know, takes away from the seriousness of it all. Then again, maybe George feels obliged to be humble. After all, how many little red books are there in history? None as good as this one. John C. Dvorak Berkeley, California October 10, 1984 Contents SOFTWARE 1 PROOGRAMMERS 5 THE INDUSTRY 9 COMPUTER DESIGN 21 BUYING COMPUTERS 27 SELLING COMPUTERS 33 CREATIVITY 41 BUSINESS/FINANCE 49 MISCELLANEOUS 55 1 Software 2 Hardware is just a pernicious little thing required to allow software to solve the application problem. Good software is software that succeeds without having to work hard in the marketplace. 'Self-teaching software' is an oxymoron--like 'military intelligence' and 'postal service.' The only industrial costs software companies have is the printing of serial numbers. What drives the prices so high is thievery. 3 Instruction sets have eternal life; once created, they never disappear. So a programmable instruction set is critical to the health of the industry. The user world would be better served if it could run software without hardware. The floppy disk and its incorporation into microcomputers has been responsible for all the software innovation that's taken place in the last five years. 4 The formula for a successful software product: It has to be technically excellent but user-hostile; that way all the consultants and software cognoscenti can write about it and feel they're making a contribution. Without the proper software, computers make very good bookends. 5 Programmers 6 Programmers are like rock stars. But with rock stars, at least you get to hear the song before you buy the record. A programmer spends six months tuning his instrument and, whether it works or not, you're paying the whole time. There's been no real change in progrmammer productivity since compilers were developed in the 1950s. Software hasn't kept up with hardware in terms of productivity improvement. 7 The key to increasing programmer productivity is universal software that runs in a wide variety of hardware environments. This will keep the programmer from having to re-invent the wheel every time a new piece of hardware comes along. Ninety percent of the software gets written in 10 percent of the time. The next 9.5 percent takes 90 percent of the time. The last one-half percent never gets done. But the software still gets solds. 8 A good programmer can only write about 250 lines of code a day. Programming speed is a universal constant. Something like the speed of light, but a lot slower. Programmers stand on the toes of those who came before them. Anyone who trusts a programmer deserves what happens to him. 9 The Industry 10 Computer companies are like desert flowers--they bloom overnight and they're gone. Manufacturers have a responsibility to ther customers to promote the use of standards. That's the only way to bring volumes up and costs down. It is the user's responsibility to promote standards. Companies that try to set their own standards should not be rewarded by getting the users' dollars. 11 'Immediate delivery' means 'we have working prototypes.' Products should die a graceful death and move on. Hanging on is a disservice to the marketplace. Adam Osborne was initially successful not because he introduced portability, but because he provided utility through bundled software. To be successful, a product must satisfy a need in the market by providing utility where there was none before. 12 Being in the microcomputer business is like going 55 miles an hour three feet from a cliff. If you make the wrong turn you're bankrupt so fast you don't know what hit you. But if you make the right turn you're on a rocket with people throwing money at you. As long as product technology is changing the Japanese can't get into the market. But let the technology settle down into a well-defined market and God help you if you're an American manufacturer getting into it today because you're going to get run over flat. Just look at what happened with 5-1/4 inch floppy drives. 13 If you want to get into the marketplace with IBM it's kind of like going to a movie--a beautifully attractive movie that you can really get into. They put you in this nice chair and say 'please sit down and be comfortable.' You're probably a little bit nervious when you first go in, but the service is so great, the surroundings are so great, the drugs are so great, you think, why not relax and enjoy it. Meanwhile, what's going on up above you is that thuis huge weight is slowly being positioned and there's a guy calling down, 'How heavy do we need to make it? We want to make sure when we drop it he's totally flat and there's no way for him to crawl out from underneath. Are you over him now? He's comfortable? 14 He's not going to jump? He's unconscious? Okay.' Kachunk. And if you don't believe that, all you have to do is look at Memorex. Or Storage Technology. Apple created a problem for the industry by attracting the attention of companies like IBM and Radio Shack. Before Apple became big and successful, the big companies sneered and held their noses whenever the word 'microcomputer' was mentioned. 15 IBM came into the personal computer market when Apple threatened their base--when they saw Apple start selling into business, into the corporate environment, especially to run VisiCalc. If Commodore had done what Chuck Peddle put it in a position to do, there would be no such thing as Apple today. There'd be no such thing as Radio Shack. Commodore would completely own the market. 16 Three major factors made the personal computer happen. One was the microprocessor -- taking the power of a computer and putting it on a piece of silicon. The others were cheap semiconductor memory and cheap mass memory -- floppy disks. Not much has happened since then. Microprocessors and semiconductor memory have just gotten bigger. 17 The microcomputer market started because there was a pent-up demand for computers. The first users were willing to do virtually anything to have a computer around--put together kits, form clubs. Next came a slightly less technical group, which still was willing to do a lot of programming to make their computers breathe. And then, instead of moving to the home, as many of us thought, the market moved into small business. 18 In the early days of the microcomputer industry, you came up with a product concept, took out an ad, got some money from orders, began to develop the product, did some more advertising. If you where really lucky, you could ship the product before people realized it had just been a figment of your imagination when you first talked about it. Today the microcomputer industry is like the fashion industry; products are only good for seven or eight months. If skirts are going up, you can always re-hem. If they're going the other way, you've got the wrong product. 19 The problem with the semiconductor industry is that theit vision is very short. In bad times they'd fire whole departments to cut costs. So engineers developed a loyalty not to individual companies, but to the industry. Once the Japanese start building your product for you, they don't know how to stop. If the market changes, you're stuck with a huge inventory. A consultant is someone who's called in when someone has painted himself into a corner. He's expected to levitate his client out of that corner. 20 Market research is a major area of abuse. It is responsible for the overcrowded Winchester disk drive market. Early market researchers called up all the companies making Winchsesters and asked them their assessment of the market; then they published a report and sent it back to the vendors. The conservative ones saw from the report that they'd underestimated the market. So the next time the researchers called them, they inflated the numbers. It finally dawned on them that they were buying their own garbage. I believe in standards. Everyone should have one. 21 Computer Design 22 The computer's hardware is its body. The software is its soul. In the early days of the personal computer industry, hardware and software were completely separate disciplines, both emotionally and technically. One didn't mix the two. You did something either in hardware or in software. Sixteen-bit machines are important because of their technological sizzle; eight-bit systems are important because you can build them cheap. 23 Sixteen bits for the sake of 16 bits is an engineer's approach to products. There's an unwritten rule in the computer industry that says each new product must have special bells and whistles to spark the customer's interest. This has kept costs high and made the buyer pay for benefits of questionable value. Customers in the low-end segment of the market have been victimized by vendors who concentrate on product differentiation for its own sake instead of on what those customers really need. 24 The engineer who gets carried away with bells and whistles should be required to spend time in the customer service department--then he can see what it's like to support those additional features he's dreamed up. The formula for a successful hardware product: take a technology that can't fail but that is too immature for a big company like IBM to be comfortable with, and run with it. Using liquid crystal displays on portable computers is a current example. Tooling is an opportunity to waste money. 25 One of the great mysteries of life is how the printer and computer get hooked together. Mediocrity or adequacy is all most people need in a computer. Successful products are simple products. If George Lucas designed a lunch pail for Darth Vader, it would look like a Kaypro. 26 27 Buying Computers 28 The most important thing in buying computer hardware is to buy as little as possible. The less you buy at a given time, the more you'll be informed about what to do next. Small computers let you computerize in small clumps. You find out right away what will work and what won't. If it doesn't work you've wasted $2,500; that's better than spending $50,000 and wasting the time of a whole department. 29 Always use the 6-18 month rule in buying a computer. It takes about six months to bring a user up to speed on a new machine, so the system can't be expected to pay for itself before that. On the other hand, if it hasn't paid for itself in 18 months, it shouldn't have been purchased in the first place. Technology is changing so rapidly that a user should consider his needs only as far as 18 months down the road. Then he can upgrade, taking advantage of the knowledge he's gained by experimenting with his first system. Short-sightedness is a virtue when it comes to choosing a computer system. Know what you need now--not two years from now. 30 A user should need at least two applications before he purchases a computer. Every small business in this country needs at least two computers. Choose your hardware only after you've chosen your software; the complexity of the software will determine the appropriate hardware. The more exotic a user's software needs, the more expensive the hardware will be. 31 The user's only interest in a CPU should be whether or not his software will run on it. Memory and peripherals, however, are much more important because they determine how much you can do and how fast you can do it. People who call systems user-friendly don't know what the first-time user thinks about. You never know what to spend on a computer until after you've spent it. 32 About 35 percent of the people who buy computers don't need them. They're potentially unhappy users who'll spread bad news about computers. If you're spending your own money on a computer, shop arouund for the best value. If you're spending your company's money, buy IBM; that's the safe route. 33 Selling Computers 34 Bundling software with hardware lets the customer 'test-drive' the computer so he knows how it'll work before he buys. That means security. Computer distribution channels are not well. Sixty percent of their business has gone away and it's not coming back. Today the government and big corporations are buying direct from the IBMs, Sperrys, the Burroughs, the ITTs. 35 There's a difference between computer dealers and office equipment dealers... At COMDEX (Computer Dealers Exposition) you introduce a product and computer dealers will attack you...they're turned on by technology. At NOMDA (National Office Machines Dealers Assn.) the guy strolling by looks at the booth and says "Ah, computers...we'll have to get into that some day." Office supply dealers should become more venturesome, computer dealers more cautious. 36 Computers should be made affordable to the mass market. Computer makers should first decide what prices will make this possible, then find ways to build computers that can be sold for those prices. In the old days, our customers were as technically competent as we were, or more so. They bought from us because they had an emotional need to have a computer. Today's customers are less technically aware. They buy machines because they think they can do something practical with them. We have to show them it's worth the price. 37 We're not selling toothpaste or bubble gum or soft drinks, in which there's no difference in the basic product from one year to another except packaging. We're selling technology, and there's a difference. Look at Detroit. In the early days, the auto industry was run by engineers and technical types. It was only later, to squeeze every last dollar out of profit, that they brought in the bean-counters. And as soon as they did that, Japan came in, and there wasn't anything left. 38 Not everybody needs a computer. If a dealer sells one of my computers to the wrong person, my reputation and the dealer's are on the line. Only two groups benefit--the phone company and United Parcel Service. All the computers that have been sold so far have been sold to people who knew they wanted computers. That market is saturated. The real test will be our ability to sell to people who have never had a burning desire to own a computer because they didn't know what they could use it for. 39 Adam Osborne was the first hardware manufacturer to recognize what bundling software could do for the user. I watched what he did and figured that if a little software was good, a lot would be even better. With bundled machines you can throw away the hardware and keep the software, and it's still a good buy. 40 41 Creativity 42 The most valuable thing you can make is a mistake--you can't learn anything from being perfect. Children have an easier time learning about computers than adults because they're not afraid to make mistakes. Children are used to making mstakes all day long and getting yelled at for it. So they're more willing to experiment with something that might intimidate them. Adults can't experiment because they won't risk mistakes. The computer is simply a device to amplify mental powers. It provides leverage for your mind. 43 A technologically reckless person is one who knows just enough technology to be dangerous but not enough to be cautious. You're not trying hard enough if you don't fail sometimes. You can only tell if you're breaking ground if you're stubbing your toes. Engineers add parts to machines to solve problems; I take parts out of machines to solve problems. The people who make money in this industry are the ones who engineer a product and get others to build the parts. 44 I listen to the marketplace better than anyone else, and I don't mind borrowing. Never do anything yourself if someone else can do it better. The stabilization of markets encourages big business; upheaval and innovation encourage small business. For my father's generation, work was not supposed to be pleasant. For me, work is the greatest pleasure. I'm not a workaholic, I'm a work enthusiast. The most potent drug of all is being on a "hot" project. 45 The most successful company isn't the first one with a good idea. It's amazing how smart you can be if you're second and do your homework. My first microcomputer was an attempt to understand Osborne's success. When a company gets bigger, it can't afford to be adventurous. If it gets into high volumes, it has to stick with established technology, take what it knows works. 46 Most of us in the early days had entrepreneur's sickness--we wouldn't do anything that would dilute our control of our companies. Steve Jobs of Apple was the only one smart enough to see that he had to give away parts of his company to get the most talented people. You can still have ideas, develop products, without being entrepreneurial. Entrepreneurial just means you gamble a lot. Apple hasn't been entrepreneurial for some time and neither has H-P. 47 Being a successful entrepreneur means being able to do it more than once. If you can't repeat your success, you probably were just lucky the first time. 48 49 Business/Finance 50 Venture capitalists are like lemmings jumping on the software bandwagon. Japanese accounts payable are like heroin; they get you hooked with 120-day payment plans. The best way to keep the competition out is to price low; if there's too much fat in the profit, someone else will come in under you. I'm happy with 10 percent after-tax profits. After 15 percent I rebel; that's rape. 51 The Morrow theory of finance: When you're a little guy operating out of a garage, you have to pay all your own bills. But when you get more successful, you get a line of credit, and the bank starts paying your bills. Then you get a little more successful, and the bank won't pay anymore, so you pay your bills slowly--30, 60, 120 days late--and now your vendors are paying your bills. Now you're even more successful, you get venture capitalists, and they're paying your bills. And it used to be when you reached the highest level of success, you could go public and have the public paying your bills. But nowadays, when you finally reach the pinnacle of financial success--like Chrysler--you're so successful you can't be allowed to fail, and the government starts paying your bills. 52 People in Silicon Valley don't like the first stage--paying their own bills. They've been very successful at leapfrogging this step, by getting venture capital up front. Big corporations used to sneer at small computer companies; but the small companies forced the big ones to get into the small computer business. Money coming in says I've made the right marketing decisions. If you make enough units of a product, front-end costs are insignificant noise. 53 Money is the only lethal drug available on a non-prescription basis. Bankers aret he druggists. It's a definite sign of success when your vendors pay your bills. U.S. venture capitalists will hold on while a firm dies, to get more money for it. They deliberately prolonged Osborne's existence. At the end, with every Osborne I they shipped, they lost at least $200. 54 Venture capitalists don't know how to decide which companies are going to be successful. They don't have the slightest idea what the ingredients of a success are. The only thing they know is what worked the last time. They have a tendency to repeat. They'll work it to death. When Osborne first came out he had a startling product that captured people's imaginations. Then everybody began building portables. If you had an idea for a computer with a handle on it, it was easy to go out and get venture capital. The good thing about venture capital is that it provides a lot of jobs. 55 Miscellaneous 56 The MIS department wants control of the computer revolution; they have power and position and want to protect it. But the insurrection will win; as micros get cheaper, more and more of them will enter the corporation. They may be hidden, but they'll be there. As an organization leaves the startup phase and grows, it needs a different kind of employee--one who doesn't have to see the job from start to finish. There'll be a special place in hell for the tape back-up people. 57 User groups are an excellent device to bring pressure upon manufacturers. If I had a business that relied on kids sticking quarters in a machine, I couldn't sleep at night. People think computers will keep them from making mistakes. They're wrong. With computers you make mistakes faster. The small businessman is smart; he realizes there's no free lunch. On the other hand, he knows where to go to get a good inexpensive sandwich. 58 More money has been wasted in artificial intelligence than in any other area of computer technology. We're still not close to having any real idea or model of how the human brain works. Networking hasn't come of age. For right now, carrying a floppy disk from one computer to another is probably still the most effective way to transfer information. Ths is the ultimate con game--I'm having fun and people pay me to do it. 59 Lawyers. The worst parasites this country has produced. The guy who knows about computers is the last person you want to have creating documentation for people who don't understand computers. Portable computers took off because people seem to want handles on their computers--handles that don't really serve them well. People are attracted to handles. 60 Western Union had the chance to buy the telephone patents in 1883 for $40,000--even then a drop in the bucket. They didn't do it because they thought they were in the telegraph business, when really they were in the communication business. Similarly, the railroads didn't realize they weren't in the train business, but the transportation business; so they sat back and watched as cars and planes took it away from them. I don't know what business I'm in. The computer business? The information business? Somebody at IBM knows what business they're in. If there's one thing I'd like to find out, it's what business IBM thinks they're in. They're sure not telling anyone. -- Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org [ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] [ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]

22 years

UV Eraser assistance in NY...

by dwight.elvey＠amd.com

>From: cvendel(a)att.net > >Hi, > >Sorry to post off topic, but I'm in a bit of a bind... > >Anyone in the Westchester/Putnam area have a spare UV Eraser that they could either loan or trade with me??? I have a project I need to work on and my UV eraser has completely up and died, looks like the transformer and I really need to update some eprom's to complete code testing for work. > >I a spare VT320, a vaxstation, Atari PC-1 computer, Odyssey2 Video game console and several other items I'd be willing to do a trade for, I also have some tape drives, cd-roms drives and token ring equipment, SCSI cards, older ISA ethernet adapters and so forth if anyone is interested, please contact me off-list if you can help me out, thanks much! > >Curt >cvendel(a)att.net > Hi It is most likely a balast and not a simple transformer. They can usually be replaced by another balast of the same wattage. These can be bought from electrical shops. The bulbs are a little harder to find but they can be ordered from most any electrical shop ( they are expensive, having quartz glass tubes ). Dwight

22 years

Tek 4115B out there

by aek＠spies.com

I have the entire unit > with keyboard, manuals, etc; in storage -- I've been looking for the service manual for 411x series terminals for a while now. I'd like to scan it if you have a copy.

22 years

ASR-33....its alive (sort of)

by CPUMECH＠aol.com

Try Dataterm Inc. for Teletype parts. 781-938-1010 or Dataterm.com.

22 years

← Newer
1
...
26
27
28
29
30
31
32
...
67
Older →

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 August 2004