lcs@remus.rutgers.edu (Lyle C. Seplowitz) (02/17/91)
Does anyone have RUN's GEOS Companion Disk. I just received it today
and have encountered two problems. Since it is Saturday, I cannot call
RUN until Monday...I thought this newsgroup might provide a faster
solution.
The first problem is most serious to me (since it is one of the main
reasons for purchasing this package), the 1581 Bootmaker program does
not work properly. It creates the bootdisk and all the files. I copied
the suggested files over to it and then turned off the computer and
tried to boot GEOS with the 1581 bootdisk. Everything goes fine,
except at the very end of the load, after the deskTop is fully
displayed, the computer crashes and GEOS reports a "system error near
xxxx" dialogue box that is continuously redrawn. I tried removing the
two autoexec files (Center 80 and geoWizard), but that didn't help. I
made sure the the configure 2.1 file was configured properly, but that
didn't help.
Can anyone help me with this problem?
The other problem is with the Batch Filecopier, it doesn't allow you
to copy files from one disk to another. When you select the "Copy"
button, a dialogue box comes up but no files are in it! What's the
problem?
HELP HELP HELP HELP!
--
-------------------------------------------------------------------------------
:) :( :> :< :] :[ ;) :| :? :} :{ :* :^) :^( :+ :-) :\ :/ :! :$ :' :@ :O :# :<>
l c s @ r e m u s . r u t g e r s . e d u
-------------------------------------------------------------------------------
Everything stated or expressed in this post is strictly my opinion or viewpointrknop@nntp-server.caltech.edu (Robert Andrew Knop) (02/17/91)
lcs@remus.rutgers.edu (Lyle C. Seplowitz) writes: >The first problem is most serious to me (since it is one of the main >reasons for purchasing this package), the 1581 Bootmaker program does >not work properly. It creates the bootdisk and all the files. I copied >the suggested files over to it and then turned off the computer and >tried to boot GEOS with the 1581 bootdisk. Everything goes fine, >except at the very end of the load, after the deskTop is fully >displayed, the computer crashes and GEOS reports a "system error near >xxxx" dialogue box that is continuously redrawn. I tried removing the Hmmm... I had trouble with the 1581 bootmaker, but that wasn't it. First question: what version of GEOS are you using? I don't know this, but I suspect it may only work with 2.0. Maybe not. Second: the problem I did have was, after creating the boot disk, I started moving files around on the disk so they were all organized prettily by page. When I was done, I discovered that the first three files on the disk, the system files, had vanished! Further investigation showed that their directory entries had been replaced with all 0's; this I was able to rectify easily enough (nowadays I keep on my two 1581 boot disks copies of track $28, sector 0, in case I need to restore it). Check your boot disk to make sure that the system files are still there. If you still have trouble with it, send me a complete description in the mail, and I'll ask Jim Collette (the author) on Q-Link. -Rob Knop rknop@tybalt.caltech.edu
cs4344af@evax.arl.utexas.edu (Fuzzy Fox) (02/18/91)
In article <Feb.16.20.03.19.1991.21111@remus.rutgers.edu> lcs@remus.rutgers.edu (Lyle C. Seplowitz) writes: >The first problem is most serious to me (since it is one of the main >reasons for purchasing this package), the 1581 Bootmaker program does >not work properly. For what it's worth, I can't get the boot maker to work properly either, but since I only have a 1571, I don't mind so much. >The other problem is with the Batch Filecopier, it doesn't allow you >to copy files from one disk to another. When you select the "Copy" >button, a dialogue box comes up but no files are in it! What's the >problem? The Batch Copier is *NOT* made to copy files casually. If you just want to copy a few files around, use the DeskTop! It will do it just as efficiently! The way the Batch Copier works is this: First, you must create a 'list file'. This is a file that contains the names of the files you want to copy. You must create this file and save it to disk. Then, when you select the 'COPY' option in Batch Copier, it will find this list of files to be copied, and do the copying. It's done this way because sometimes you want to copy the same batch of files over and over, and you don't want to keep re-selecting the files with DeskTop. *THIS* is when you should use the Batch Copier. By the way, once you create the list file, you can copy files without going through this procedure...just double-click the list file, and it will load Batch Copier and copy the files and come back to the DeskTop. -- David DeSimone, aka "Fuzzy Fox" on some networks. /!/! INET: an207@cleveland.freenet.edu / .. Q-Link: Fuzzy Fox / --* Quote: "Foxes are people too! And vice versa." / ---
cs4344af@evax.arl.utexas.edu (Fuzzy Fox) (02/18/91)
In article <1991Feb17.024528.17465@nntp-server.caltech.edu> rknop@nntp-server.caltech.edu (Robert Andrew Knop) writes: >Second: the problem I did have was, after creating the boot disk, I started >moving files around on the disk so they were all organized prettily by page. >When I was done, I discovered that the first three files on the disk, the >system files, had vanished! Further investigation showed that their directory >entries had been replaced with all 0's; this I was able to rectify easily >enough (nowadays I keep on my two 1581 boot disks copies of track $28, sector >0, in case I need to restore it). Check your boot disk to make sure that the >system files are still there. The problem you describe is an intentional Trojan Horse created by Berkeley themselves. When the DeskTop discovers that you have a Boot Disk in the drive, it checks the copy protection on the disk, and if it fails, the first three directory entries are zapped. (On a boot disk they correspond to GEOS, GEOS BOOT, and GEOS KERNAL.) This is to keep you from copying your Boot Disk. There are a couple ways around this problem. 1. You can write-protect your boot disk. Even GEOS can't write to a write-protected disk, but that means you can't ever change your config- uration again without risking your files getting zapped. 2. You can use an alternate DeskTop. WormDesk or QwikTop come to mind, but there are still some nifty things you can only do from DeskTop. Maybe the best thing to do is wait for GateWay? 3. You can change the disk header to show that the disk is not a Boot Disk. As you know, there are three kinds of disks in GEOS: Boot, Master, and Work Disk. A Boot disk and a Master disk are the same to the DeskTop (ie, you can't delete files without moving them to the border first, and other things). However, Boot disks are also scanned by the Trojan Horse check. If you change the disk type from Boot to Master, GEOS will stop zapping your files. However, those bright minds at Berkeley have thought of this one, too. During the Boot process, if GEOS detects you are booting from a non-Boot disk, it will change the disk back to Boot! Another reason to write-protect your disk, eh? However, if you were inclined, you might be able to write an auto-exec to change the disk type back to Master, before DeskTop gets control. Perhaps the best course of action is to contact GeoRep Jim and find out why his boot disk is succeptible to this Berkeley Trojan? You'd think that he would have discovered this problem while building the program. -- David DeSimone, aka "Fuzzy Fox" on some networks. /!/! INET: an207@cleveland.freenet.edu / .. Q-Link: Fuzzy Fox / --* Quote: "Foxes are people too! And vice versa." / ---
roger@garfield.cs.mun.ca (Roger White) (02/18/91)
>In article <1991Feb17.024528.17465@nntp-server.caltech.edu> rknop@nntp-server.caltech.edu (Robert Andrew Knop) writes: >>Second: the problem I did have was, after creating the boot disk, I started >>moving files around on the disk so they were all organized prettily by page. >>When I was done, I discovered that the first three files on the disk, the >>system files, had vanished! Further investigation showed that their directory >>entries had been replaced with all 0's; this I was able to rectify easily >>enough (nowadays I keep on my two 1581 boot disks copies of track $28, sector >>0, in case I need to restore it). Check your boot disk to make sure that the >>system files are still there. > >The problem you describe is an intentional Trojan Horse created by >Berkeley themselves. When the DeskTop discovers that you have a Boot >Disk in the drive, it checks the copy protection on the disk, and if it >fails, the first three directory entries are zapped. (On a boot disk >they correspond to GEOS, GEOS BOOT, and GEOS KERNAL.) This is to keep >you from copying your Boot Disk. > >There are a couple ways around this problem. > >1. You can write-protect your boot disk. Even GEOS can't write to a >write-protected disk, but that means you can't ever change your config- >uration again without risking your files getting zapped. > >2. You can use an alternate DeskTop. WormDesk or QwikTop come to mind, >but there are still some nifty things you can only do from DeskTop. >Maybe the best thing to do is wait for GateWay? > >3. You can change the disk header to show that the disk is not a Boot >Disk. As you know, there are three kinds of disks in GEOS: Boot, > >-- >David DeSimone, aka "Fuzzy Fox" on some networks. /!/! >INET: an207@cleveland.freenet.edu / .. >Q-Link: Fuzzy Fox / --* >Quote: "Foxes are people too! And vice versa." / --- > 4. Do what I did... get your multi-purpose 1581 disk editor and look at the directory sector containing the boot programs (40,3). Four positions after the filename is the file type. It should be 12 decimal ($0C hex) to represent a system boot file. All you have to do is change that 12 to a 6 and the file will no longer be a system boot but an application. My disk boots perfectly since I did that and the files are no longer erased. It is a very simple fix and doesn't harm your files in any way. The only change is that the boot programs will be seen as applications, and you may be able to run them from the desktop (not recommended!). (Of course, Maverick's 1581 convertor is much better and much faster when booting) R.White -- Boot it up? I did A LOT of that!| Roger White (Sam-Cheers) | Memorial University of Newfoundland --------------------------------| St. John's, Newfoundland, Canada ..uunet!odie.cs.mun.ca!roger, roger@odie.mun.edu, roger@odie.cs.mun.ca
rknop@nntp-server.caltech.edu (Robert Andrew Knop) (02/18/91)
cs4344af@evax.arl.utexas.edu (Fuzzy Fox) writes: >For what it's worth, I can't get the boot maker to work properly either, >but since I only have a 1571, I don't mind so much. Question: if you don't have a 1581, how do you know that the bootmaker doesn't work? Just wondering... -Rob Knop rknop@tybalt.caltech.edu
rknop@nntp-server.caltech.edu (Robert Andrew Knop) (02/18/91)
cs4344af@evax.arl.utexas.edu (Fuzzy Fox) writes: >Perhaps the best course of action is to contact GeoRep Jim and find out >why his boot disk is succeptible to this Berkeley Trojan? You'd think >that he would have discovered this problem while building the program. I actually did this; I don't remember the response in detail, but I think that he tried to deal with this, but wasn't able to fully get rid of it. As it is, almost everything will work allright- you can copy files to/from the boot disk and so forth; however, there are some things you can do, like move a file from a page to the desktop, and to another page, which causes the Trojan Horse to kick in and delete your boot files. So if you avoid this, you are OK. -Rob Knop rknop@tybalt.caltech.edu
mford@umaxc.weeg.uiowa.edu (Mark Ford) (02/20/91)
From article <1991Feb17.024528.17465@nntp-server.caltech.edu>, by rknop@nntp-server.caltech.edu (Robert Andrew Knop): > Hmmm... I had trouble with the 1581 bootmaker, but that wasn't it. First > question: what version of GEOS are you using? I don't know this, but I > suspect it may only work with 2.0. Maybe not. > > Second: the problem I did have was, after creating the boot disk, I started > moving files around on the disk so they were all organized prettily by page. > When I was done, I discovered that the first three files on the disk, the > system files, had vanished! I downloaded the 1581 bootmaker for the C-128 from Q-Link awhile ago. I ran it and everything has been just fine. It boots every time on the 1581 and my system files have never vanished. I do not have version 2.0 but the version before 2.0 came out. This means that either the bootmaker on Q-Link is not the same as the one on the disk, or Geos 2.0 has trouble with it and the Geos 128 pre-2.0 does not, or I am just lucky. Mark. mford@umaxc.weeg.uiowa.edu
cs4344af@evax.arl.utexas.edu (Fuzzy Fox) (02/20/91)
In article <1991Feb17.234810.11358@garfield.cs.mun.ca> roger@garfield.cs.mun.ca (Roger White) writes: >4. Do what I did... [...edit the file type bytes in the directory...] I fail to see how this avoids the Berkeley Trojan (isn't that a great name for it?)... The Trojan does NOT look at the directory at all, but instead checks track 18, sector 0, byte offset $BD, which is set to 0 for a work disk, "P" for a master disk, and "B" for a boot disk. If the byte is "B", and the copy protection fails, then the Trojan zaps the first three entries of the directory to zeroes, WITHOUT checking to see what they are. In effect, you can defeat the Trojan another way by moving the 3 boot files to another page on the disk, and making sure that no file ever occupies one of the first three slots on page one. (But of course GEOS won't let you move the boot files, will it? Gee, I wonder why?) You'll have to use another disk editor to do this. Anyway, I contend that you have just been lucky so far. I believe if you boot GEOS and remove the boot disk as your first action after booting, you will most likely not have a problem with your files disappearing. Try moving files around on the DeskTop for a while, and perhaps you will see the files disappear. -- David DeSimone, aka "Fuzzy Fox" on some networks. /!/! INET: an207@cleveland.freenet.edu / .. Q-Link: Fuzzy Fox / --* Quote: "Foxes are people too! And vice versa." / ---
23538@brahms.udel.edu (Stephen C Terapak) (02/21/91)
I have a ibm printer for my cbm 128 and the interface broke for it. The printer was a panasonic fx-27 and the interface was a xetec supergraphic interface. Is anybody familar with either? There are no places in Delaware where I can pick up a new one and I had a hard time finding one in the D.C. area where I live.
I thought commodore was dead...guess not.
Stephen C. Terapak
U Of Delawareroger@garfield.cs.mun.ca (Roger White) (02/25/91)
In article <1991Feb20.063301.26802@evax.arl.utexas.edu> cs4344af@evax.arl.utexas.edu (Fuzzy Fox) writes: >In article <1991Feb17.234810.11358@garfield.cs.mun.ca> roger@garfield.cs.mun.ca (Roger White) writes: >>4. Do what I did... [...edit the file type bytes in the directory...] > >I fail to see how this avoids the Berkeley Trojan (isn't that a great >name for it?)... The Trojan does NOT look at the directory at all, but >instead checks track 18, sector 0, byte offset $BD, which is set to 0 >for a work disk, "P" for a master disk, and "B" for a boot disk. If the >byte is "B", and the copy protection fails, then the Trojan zaps the >first three entries of the directory to zeroes, WITHOUT checking to see >what they are. In effect, you can defeat the Trojan another way by >moving the 3 boot files to another page on the disk, and making sure >that no file ever occupies one of the first three slots on page one. >(But of course GEOS won't let you move the boot files, will it? Gee, I >wonder why?) You'll have to use another disk editor to do this. > >Anyway, I contend that you have just been lucky so far. I believe if >you boot GEOS and remove the boot disk as your first action after >booting, you will most likely not have a problem with your files >disappearing. Try moving files around on the DeskTop for a while, and >perhaps you will see the files disappear. > >-- >David DeSimone, aka "Fuzzy Fox" on some networks. /!/! >INET: an207@cleveland.freenet.edu / .. >Q-Link: Fuzzy Fox / --* >Quote: "Foxes are people too! And vice versa." / --- Well I can't see how your explanation works... I made three copies of Geos 128 V2 without switching the filetypes. Each time while copying files over to/from that disk I lost the system boot files. All three of the disks were not able to boot again. I have been now using my 'fixed' disk for the past 6 months with no problem. I copy files to it, from it, load applications from it, delete files from it... everything you can do with it and the boot files are still there. I have two disks created like this (one for my father, one for me) and I have not lost a boot file since. If it is only a coincidence then it must be a once (twice?) in a lifetime thing. I have yet to lose a boot file in 6 months, but I lost 3 disks in only one day without changing the file type. I have never looked into the Berkeley Kernal, but I believe it deletes all the system boot files... not only the first three. Therefore changing the system boots to applications will fix the 'Berkeley Trojan'. Why don't someone else try it and report to the net their finding, all we need is one person to say that their boot files were erased to show that it doesn't work (except for me :-). I haven't tried it with the 64 version, but the 128 version works perfectly for me. Roger. -- Boot it up? I did A LOT of that!| Roger White (Sam-Cheers) | Memorial University of Newfoundland --------------------------------| St. John's, Newfoundland, Canada ..uunet!odie.cs.mun.ca!roger, roger@odie.mun.edu, roger@odie.cs.mun.ca