From X Wed Mar 31 19:40:09 CST 1993 Article: 37125 of alt.folklore.computers Path: uchinews!linac!uwm.edu!cs.utexas.edu!sun-barr!news2me.EBay.Sun.COM!cronkite.Central.Sun.COM!sixgun.East.Sun.COM!seven-up.East.Sun.COM!uk-news.uk.sun.com!sunicnc.France.Sun.COM!smckinty From: smckinty@sunicnc.France.Sun.COM (Steve McKinty - Sun ICNC) Newsgroups: alt.folklore.computers Subject: Re: Apple II+ highres memory Date: 24 Mar 1993 08:53:03 GMT Organization: SunConnect Lines: 34 Sender: smckinty@France.Sun.COM (Steve McKinty - Sun ICNC) Distribution: usa Message-ID: <1op7hfINNmco@uk-news.uk.sun.com> References: <1on8bp$bqv@armory.centerline.com> NNTP-Posting-Host: hardy.france.sun.com Status: RO In article , stevev@miser.uoregon.edu (Steve VanDevender) writes: > As someone who once hacked the Apple II, I feel the need to set > the record straight. > [snip] > > The weirdest thing about the Apple II's high-res graphics mode > was the memory addressing. Essentially, the high-res mode was > laid out so that it was easy to generate the dot stream using the > same logic that was used for text-mode character generation, > except that RAM was scanned instead of the character generator > ROM to get the pixels. It's too late at night for me to try to > describe the really odd memory layout, but it was not the > contiguous, orderly, top-to-bottom layout that you find on nearly > every other graphics system. But did you ever have the 'pleasure' or working on the European version of an Apple II, with the electronics redesigned for 625-line video? It was done by hooking one more RAM chip into place, and referencing it for every 9th pixel on a line... All the monitor software knew about that, so there was no problem using the monitor routines, but programs which directly loaded video RAM (Sargon was one) would load in an image with a series of vertical stripes 8pixels apart. Of course, none of the documentation mentioned this... Steve -- Steve McKinty SUN Microsystems ICNC 38240 Meylan, France email: smckinty@france.sun.com BIX: smckinty From X Mon Mar 15 12:09:07 CST 1993 Article: 36318 of alt.folklore.computers Newsgroups: alt.folklore.computers Path: uchinews!linac!uwm.edu!spool.mu.edu!agate!ames!news.Hawaii.Edu!montebello!joe From: joe@montebello.soest.hawaii.edu (Joe Dellinger) Subject: Early Viruses Message-ID: Sender: joe@montebello.soest.hawaii.edu Organization: School of Ocean and Earth Science and Technology References: <1993Mar12.161734.17808@vax5.cit.cornell.edu> Date: Mon, 15 Mar 1993 11:01:32 GMT Lines: 117 Status: RO In article <1993Mar12.161734.17808@vax5.cit.cornell.edu> c3q@vax5.cit.cornell.edu writes: > > 2) When Joshua/WOPR is about to launch missiles, the short >computer scientist (or maybe an assistant) says that maybe they should release >a tape-worm. The reply is that this is too risky. (Note: tapeworm is a type >of virus, or an old term for a virus, depending on who you ask...coined (I >think) by Jon Brunner in _Shockwave Rider_). I never picked up on this >reference before.... Speaking of viruses, in February's "Discover" magazine there is an excerpt from an upcoming book about viruses. Does anyone know of e-mail addresses (or postal addresses) for the authors, "Paul Mungo" and "Bryan Clough"? (If their book gives a "history" I might have some first-person accounts they'd find useful.) Since we've been hearing about the history of computing of late in this newsgroup, here's my bit to add to the history of computer viruses: Fred Cohen likes to claim he invented the term "Computer Virus" in 1983. While he may have been the first to widely publicize the term, I can personally attest that the word "Computer Virus" was already in use in 1981 at Texas A+M University, and we already had working computer viruses too. I've been trying to assemble first-person accounts of the earliest known computer viruses. The earliest I know of so far are one called "Elk Cloner", written by Rich Skrenta, and one I wrote at Texas A+M at nearly the same time which I unimaginatively called "Virus1". (I don't think Virus1 escaped, but "Virus2" and "Virus3" certainly did.) Both date to fall 1981. Elk Cloner got some press at the time because it would do occasional "tricks" such as printing this poem to call attention to itself: > Elk Cloner: The program with a personality > > It will get on all your disks > It will infiltrate your chips > Yes it's Cloner! > > It will stick to you like glue > It will modify ram too > Send in the Cloner! Stories about Elk Cloner occasionally still pop up in this newsgroup, and lots of old-timer Apple users still have "pet" copies. Virus2 and Virus3 were written as experimental "super-successful computer life forms". I was taking Historical Geology at the time, all about the history and evolution of life and how you can identify the ages of rocks by their unique assemblages of fossil life forms... It got me thinking that the set of all Apple ][ disks were analogous to a big planet, with the set of all Apple ][ programs occuring on them as life forms in competition for precious living space in which to reproduce... The whole idea behind my viruses was that they wouldn't need your HELP to copy themselves from disk to disk, and so would be "evolutionarily superior" to other programs. They also should NOT cause any detectable change in your computer's outward behavior, because if they called attention to themselves users would be motivated to hunt them down and kill them. The plan was to infect only my own personal disks (so I also had personal motivation to make the viruses as harmless as possible!). The virus incorporated a generation counter so I could see how many copies it took to saturate my disks. (Later after the virus had proven itself harmless, friends let it infect their disks as well to see how quickly it would spread.) Because my viruses had no "symptoms" (or at least no deliberate ones), after they inevitably accidentally escaped they spread unnoticed because at the time nobody was checking for viruses! They were ultra-paranoid about causing harm and would silently disconnect themselves whenever they encountered anything unusual; as a result they committed mass suicide and disappeared when modified DOS's such as Pronto-DOS replaced Apple DOS 3.3 (which is all they knew how to infect). I haven't encountered a "wild" copy of my viruses since 1984. A friend claims he recently found a copy on an old DOS 3.3 disk of his, but forgot to write down any information to prove it (like the generation count) and then misplaced the disk while moving before even getting around to telling me he had found it. (Aaargh!) Well... If one person still had a copy perhaps others do too? If you have any old _48K slave Apple DOS 3.3 disks_ (master disks and non-3.3 disks are immune) and care to check for infection, here's how: Beginning at B6E8 regular Apple ][ DOS 3.3 has a bunch of 00's. Boot the disk you want to check to load that disk's copy of DOS into memory. Infected disks or non-infectious descendants of infected disks will have text of the form "(GEN 0000000 TAMU)" (in Hex this is "A8 C7 C5 CE A0 B0 B0 B0 B0 B0 B0 B0 A0 D4 C1 CD D5 A9") at B6E8. (To display these bytes starting from BASIC you can do "call -151" followed by "B6E8L".) If you see OTHER junk go by there it's NOT my virus. (It's probably Pronto-DOS, which also uses that space.) The number is a generation count, and so will be different in your copy. (13 generations saturated my own and my friends' collections, if you're interested.) If you should find the generation count, you might try also looking at 9CFE and 9CFF. If the virus is alive, this should contain the initials of the friend of mine who let your copy of the virus escape. (If it's JD, then I'm the guilty party, although I don't *think* any "JD" copies escaped! Hard to know, though.) Chances are you won't find anything. Remember, only bother to search DOS 3.3 disks. If you have ProDos, ProntoDos, etc, etc, any of the "improved" DOS's that came out later, you will _not_ have a copy of my virus on that disk! Thanks! -- /\ /\ /\/\/\/\/\/\/\.-.-.-.-.......___________ / \ / \ /Hawaii Institute of Geophysics, Honolulu\/\/\.-.-....__ ___/ \/ \/Joe Dellinger, Internet: joe@montebello.soest.hawaii.edu\/\.-.__ ________________________________________________________________________________ From uchinews!vixen.cso.uiuc.edu!uwm.edu!cs.utexas.edu!uunet!munnari.oz.au!newshost.anu.edu.au!sserve!cserve.cs.adfa.oz.au!wkt Thu Aug 5 11:03:01 CDT 1993 Article: 45780 of alt.folklore.computers Newsgroups: alt.folklore.computers Path: uchinews!vixen.cso.uiuc.edu!uwm.edu!cs.utexas.edu!uunet!munnari.oz.au!newshost.anu.edu.au!sserve!cserve.cs.adfa.oz.au!wkt From: wkt@cserve.cs.adfa.oz.au (Warren Toomey) Subject: Re: Really small UNIX boxen Message-ID: <1993Aug5.031300.5217@sserve.cc.adfa.oz.au> Sender: news@sserve.cc.adfa.oz.au Organization: Australian Defence Force Academy References: <1993Aug5.005950.17799@monu6.cc.monash.edu.au> Date: Thu, 5 Aug 1993 03:13:00 GMT Lines: 30 Status: RO In article <1993Aug5.005950.17799@monu6.cc.monash.edu.au>, ins559n@aurora.cc.monash.edu.au (Andrew Bulhak) writes: |> I have heard a while ago that someone got some sort of UNIX-like operating |> system to run on an Apple II. Has anyone else heard this? I rewrote Xinu for the Apple ][, in 6502 assembly code, just for fun. It was so quirky: - context switching involved saving/loading registers, the zero page and the stack -- very slow. - the Apple ][ didn't have a hardware clock. I built up one and used the IRQ line to prompt the OS. - all disk I/O _had_ to be done in software with timed loops. The system lost time during disk I/O. - all processes had to be written in posn-indep code; the 6502 doesn't have any memory hardware. - the shell and some builtins (like ls) were built into the OS (shareable). - I used ProDOS' disk structure as it was hierachial, not flat like DOS 3.3. I tried getting the Uni to allow this to be my Honour's project, but they turned me down. Oh well...... Warren Toomey wkt@csadfa.cs.adfa.oz.au From uchinews!linac!uwm.edu!wupost!howland.reston.ans.net!math.ohio-state.edu!cs.utexas.edu!swrinde!network.ucsd.edu!qualcomm.com!happy!rdippold Tue Oct 12 20:36:01 CDT 1993 Article: 49687 of alt.folklore.computers Path: uchinews!linac!uwm.edu!wupost!howland.reston.ans.net!math.ohio-state.edu!cs.utexas.edu!swrinde!network.ucsd.edu!qualcomm.com!happy!rdippold From: rdippold@qualcomm.com (Ron "Asbestos" Dippold) Newsgroups: alt.folklore.computers Subject: Re: Question about Apple II drives Date: 8 Oct 93 20:39:09 GMT Organization: QUALCOMM, Incorporated; San Diego, CA, USA Lines: 88 Message-ID: References: <292noa$nja@news.delphi.com> NNTP-Posting-Host: happy.qualcomm.com Originator: rdippold@happy.qualcomm.com Status: RO dcongdon@news.delphi.com (DCONGDON@DELPHI.COM) writes: >Can anyone out there give me a good, technical explanation of >Woz's method for controlling disk drives as opposed to the more >conventional approaches. This interests me both from an historical The Disk ][ hardware basically did three things - read byte, write byte, move from track to track. Everything else was done in software. Instead of telling the controller to read block X, or track X sector Y you did all the work yourself. Here's what you'd do to read a sector: Note your current position. Note where you want to go. Turn on the drive. Move the head a quarter track at a time by playing with the stepper motor control registers. Read a raw byte of data (probably have to wait for it). Check to see if the byte is the first of those reserved as the address field header. If not, keep reading When it is, read the next two bytes and see if they match the address field prefix. If not, keep reading. otherwise, continue. Read the address header. The fields are two bytes long - AND them to get a single byte. More on why later. Check the address header checksum. See what the track number in the address field is - if we are where we think we are, continue. Otherwise, back to the top (this should happen only in very rare situations). Check the sector field in the address field. If it is the right sector, continue, otherwise go back to looking for more address fields. Wait for the data field header, same as with the address field but with different flag bytes. Read the sector data into memory a byte at a time. Check the checksum. If it's bad, "reset" the drive and try again. Decode the raw data into actual data. The data stored on the disk was not stored as you might expect - the system had the limitation that it couldn't (easily) tell the difference between a zero and two zeroes in a row. So all bytes written to the disk had to have no more than one zero in a row! To get around this, they used different encoding methods that worked pretty well given the limitations. For the address fields, which are small, they just split each byte into two bytes and turned the odd bits to 1s in one and the even bits to 1 in the other. To reconstruct them you just AND them together (it's been a while, but I'm pretty sure this was the method - certainly something similar). For the data bits, they used two encoding methods - DOS 3.2 and earlier had, I believe, a 5 and 3 method, which allowed 13 sectors per track. DOS 3.3 had a 6 and 2 method, which allowed 16 sectors per track. I _liked_ the controlling being done in software. It allowed all sorts of nifty tricks. I (others did too) made a disk that was one huge spiral - you could control the head down to a quarter track level - you lay down the data and every quarter track you move the head. The disk boots phenomenally fast. You could insert multiple zeroes into the data (it affected the timing). Custom disk formats were no problem. Plus, the algorithms for reading and writing were simple (Woz made the hardware interface very easy) and small, especially if you had Beneath Apple DOS (what a book! the hacker's dream...). Different people came up with faster transparent replacements for Apple's DOS, which were easy to upgrade on all your disks because everything _was_ done in software. I wrote a boot program that lived on the first track - you could put the disk in, power up, and have your choice of programs on the disk to run within 2 seconds of power on. 1 second from a reboot. You couldn't run programs that required DOS this way, but a surprising number of them didn't. The design also allowed full track read/write - I could entirely copy a disk to an unformatted disk in 18 seconds, including read, write, and verify. The PC floppy was very slow in comparison. In addition, the computer kept the disk running at full speed - it read and wrote as fast as the disk hardware would allow. It's an interesting contrast to my C-64 drive, which had all the smarts inside, so that you could hook two of them together and let they copy disks without a computer attached, but was such a f'ing slow hog. You could eventually get a hardware upgrade to speed it up, like Epyx's fastloader cartridge. Fun Fact: DOS 3.3 was slow mostly because Woz got the interleave wrong. It spent most of its time waiting for the disk to come around again because it just missed the next sector. The earliest speed enhancers simply reinterleaved the floppies to 3:1 for a dramatic speed increase. Later ones used more efficient read/write routines, allowing the same 2:1 interleave, but fast enough to decode one sector before reaching the next next sector, for blazing speed. Fun Fact 2: The first Apple // 3 1/2" drive had a 65c02 in it that did most of the work. The second, and faster, 3 1/2" drive let the computer do most of the work. In addition, Diversi-Cache could work with the software controlled drive for a 5 times speed increase, but not with the first. -- It's here at last: Released a 26-week project in 48 weeks.