bscott@nyx.UUCP (Ben Scott) (07/09/90)
In article <6600012@okcusr.UUCP> bn@okcusr.UUCP writes: >> not clearing memory location 0. Well, I found that a few of the PD programs [..] >> in AmigaBasic. Does anyone out there has a summary of the consequences of >> doing a POKEL 0, 0? Also is there a better way of doing this? > >I am also having this problem with my brand new A590. I found that VirusX3.2 >works like a charm, but 4.0 crashes when it's trying to set up. Another >problem that I'm having is that ever since I installed the HD, some of my >file requesters contain the string "gdos" as though the DOS already selected [...] >because the term assumes I want to upload a file called "gdos". Does >anybody know a cure for this??? By the way, the problem mentioned in the This keeps popping up so I'm posting publicly (perhaps this is a candidate for the Intro to c.s.a. file?) - also due to some problems I can't reliably post mail replies on comp.sys.amiga... anyhow: There's a simple, clean fix for this. Go in through HD_Toolbox, to "Partition Drive", then click on "Advanced Options" and you'll see a box labeled "Add/ Update Filesystems" - click this and then change the version number of the FFS from 0 to 1. Note that this changes the FFS on the hardblocks, the one in L: is unaffected and does not even need to be there unless you're running other FFS devices. Version 0 as shipped is a debugging version of some kind, which puts a pointer to someplace in memory which has the string "gdos" in it - (not sure what but it's probably a memory resident library someplace) - buggy programs which have uninitialized pointers or which expect a null to be in location zero will find what appears to be a null-terminated string pointed to by the number at 0. This will cause annoyances and sometimes crashes depending on the program. Note also that this is a kind of bug, but it only affects other buggy programs. Location zero is not to be played with or counted on to have zero in it. It was an oversight to ship version 0 enabled instead of version 1, so you can't really call it a bug. Once you make the switch all problems will go away. . <<<<Infinite K>>>> -- .---------------------------------------------------------------------------. |Ben Scott, professional goof-off and consultant at The Raster Image, Denver| |Amiga UUCP node domain: bscott@vila.denver.co.us Else: bscott@nyx.cs.du.edu| |FIDO point address 1:104/421.2, or call the Arvada 68K BBS at (303)424-9831| |"Don't embarrass us..." "Have I ever?" - Buckaroo Banzai | *AMIGA POWER* | `---------------------------------------------------------------------------'
" Seaman) (07/12/90)
bscott@nyx.UUCP (Ben Scott) writes: < bn@okcusr.UUCP writes: < >I am also having this problem with my brand new A590. I found that VirusX3.2 < >works like a charm, but 4.0 crashes when it's trying to set up. Another < >problem that I'm having is that ever since I installed the HD, some of my < >file requesters contain the string "gdos" as though the DOS already selected < [...] < >because the term assumes I want to upload a file called "gdos". Does < >anybody know a cure for this??? By the way, the problem mentioned in the < < This keeps popping up so I'm posting publicly (perhaps this is a candidate for < the Intro to c.s.a. file?) - also due to some problems I can't reliably post < mail replies on comp.sys.amiga... anyhow: < < There's a simple, clean fix for this. Go in through HD_Toolbox, to "Partition < Drive", then click on "Advanced Options" and you'll see a box labeled "Add/ < Update Filesystems" - click this and then change the version number of the FFS < from 0 to 1. Sorry, but this doesn't fix anything. I have had this problem since the day I installed my 2091, and NONE of the suggested fixes have done anything. I have a 2091 with a Quantum 105MB drive (purchased SEPARATELY). The drive did not come with ANY filesystem installed on the RDB. The version which came on the 2091 Installation disk matches the 'correct' version in every respect (the size, the embedded version string, the timestamp on the file, etc). This has been verified by someone at Commodore (though I've forgotten who). Suffice it to say that I am still forced to manually poke a 0L into address 0 on every reboot, or MANY programs fail miserably. < Version 0 as shipped is a debugging version of some kind, which puts a pointer < to someplace in memory which has the string "gdos" in it - (not sure what but < it's probably a memory resident library someplace) - buggy programs which have < uninitialized pointers or which expect a null to be in location zero will find < what appears to be a null-terminated string pointed to by the number at 0. < This will cause annoyances and sometimes crashes depending on the program. < Note also that this is a kind of bug, but it only affects other buggy programs. < Location zero is not to be played with or counted on to have zero in it. < < It was an oversight to ship version 0 enabled instead of version 1, so you can't < really call it a bug. Once you make the switch all problems will go away. < < . <<<<Infinite K>>>> Believe me, I REALLY wish this was the case. Unfortunately, it isn't. In fact, the version of FFS that I use with the 2091 is IDENTICAL to the version I used on my 2090a, which never caused any problems. Whatever the problem is, it is not in the filesystem. If anyone has any other ideas, I am willing to try anything. However, I have tried the 'change the version to 1', 'manually force the filesystem to be updated', 'install the filesystem from another Workbench disk' tricks more times than I care to mention. So please, DON'T suggest I do these things again. THEY DON'T FIX THE PROBLEM! -- Chris (Insert phrase here) Seaman | /--\ cseaman@sequent <or> | | | "This is as real as ...!uunet!sequent!cseaman | | \ | your so-called 'Life' gets" The Home of the Killer Smiley | \--X__
dylan@cs.washington.edu (Dylan McNamee) (07/13/90)
In article -38440@sequent.UUCP= cseaman@sequent.UUCP (Chris "I'm Outta Here, Man!" Seaman) writes: =bscott@nyx.UUCP (Ben Scott) writes: =- bn@okcusr.UUCP writes: =- There's a simple clean fix for this. Go in through HD_Toolbox, to "Partition =- Drive", then click on "Advanced Options" and you'll see a box labeled "Add/ =- Update Filesystems" -click this and then change the version number of the FFS =- from 0 to 1. = =Sorry, but this doesn't fix anything. I have had this problem since the =day I installed my 2091, and NONE of the suggested fixes have done anything. =Believe me, I REALLY wish this was the case. Unfortunately, it isn't. In fact, My experience agrees with Chris's; changing the version number did nothing at all. I still have to run my (56 byte!) clearZero C program. =If anyone has any other ideas, I am willing to try anything. However, I =have tried the 'change the version to 1', 'manually force the filesystem =to be updated', 'install the filesystem from another Workbench disk' tricks =more times than I care to mention. So please, DON'T suggest I do these =things again. THEY DON'T FIX THE PROBLEM! Ok, so what's going on here? Either some people have 'mutant' 2091's that respond to the filesystem version change, or the helpful people that have suggested the "simple clean fix" aren't running the same system. (Mine is a stock 2500/30.) =Chris (Insert phrase here) Seaman | /--\ dylan -dylan@cs.washington.edu
olson@donald.uhcc.Hawaii.Edu (Todd Olson) (07/14/90)
In article <12541@june.cs.washington.edu> dylan@june.cs.washington.edu (Dylan McNamee) writes: >In article -38440@sequent.UUCP= cseaman@sequent.UUCP (Chris "I'm Outta Here, Man!" Seaman) writes: >=bscott@nyx.UUCP (Ben Scott) writes: >=- bn@okcusr.UUCP writes: >=- There's a simple clean fix for this. Go in through HD_Toolbox, to "Partition >=- Drive", then click on "Advanced Options" and you'll see a box labeled "Add/ >=- Update Filesystems" -click this and then change the version number of the FFS >=- from 0 to 1. >= >=Sorry, but this doesn't fix anything. I have had this problem since the >=day I installed my 2091, and NONE of the suggested fixes have done anything. >=Believe me, I REALLY wish this was the case. Unfortunately, it isn't. In fact, > >My experience agrees with Chris's; changing the version number did >nothing at all. I still have to run my (56 byte!) clearZero C program. > And mine agrees with the above two. >Ok, so what's going on here? Either some people have 'mutant' 2091's >that respond to the filesystem version change, or the helpful people >that have suggested the "simple clean fix" aren't running the same >system. (Mine is a stock 2500/30.) > My system is a 2000 that has become a 2500/30. > >dylan -dylan@cs.washington.edu Todd PRIVATE TO PERRY K at ASDG below Perry have you started to work on the new code for the dual serial board. I am still haveing lock up problems with anyhthing that uses interrupts. BTW is there someway I could get another registration card or become a registered owner as I lost the card in the move after I received the DSB. Thanks, Todd -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/ | "Take your work seriously, but never take \/ /\ olson@uhunix.uhcc.hawaii.edu | yourself seriously and do not take what /\ \/ olson@uhccux.uhcc.hawaii.edu | happens either to yourself or your work \/
bscott@nyx.UUCP (Ben Scott) (07/14/90)
In article <38440@sequent.UUCP> cseaman@sequent.UUCP (Chris "I'm Outta Here, Man!" Seaman) writes: >bscott@nyx.UUCP (Ben Scott) writes: >< There's a simple, clean fix for this. Go in through HD_Toolbox, to "Partition >< Drive", then click on "Advanced Options" and you'll see a box labeled "Add/ >< Update Filesystems"- click this and then change the version number of the FFS >< from 0 to 1. > >Sorry, but this doesn't fix anything. I have had this problem since the [...] >who). Suffice it to say that I am still forced to manually poke a 0L into >address 0 on every reboot, or MANY programs fail miserably. Does too does too! At least it worked like a charm on my A-590. My explanation of the actual cause may or may not have been accurate but the fix DOES work for me and everyone I've heard about (until now). >Believe me, I REALLY wish this was the case. Unfortunately, it isn't. In fact, >the version of FFS that I use with the 2091 is IDENTICAL to the version I >used on my 2090a, which never caused any problems. Whatever the problem is, >it is not in the filesystem. You may have hit on the problem... I mean, the only thing I can think of is that it is NOT the 2091 that's doing this to your location zero. Check every other program in your startup (even the normal C: commands) and see if it's one of them. If you really are running version 1 of the 1.3.2 FFS, then I think it's unlikely that it's trashing location zero. And what do you mean by "many" programs failing? I never found any that actually died - most just exhibited that weird "gdos" string showing up or reported errors after they finished doing their jobs. At any rate a program affected by a trashed location zero is itself buggy, usually because of trying to use an uninitialized pointer. . <<<<Infinite K>>>> -- .---------------------------------------------------------------------------. |Ben Scott, professional goof-off and consultant at The Raster Image, Denver| |Amiga UUCP node domain: bscott@vila.denver.co.us Else: bscott@nyx.cs.du.edu| |FIDO point address 1:104/421.2, or call the Arvada 68K BBS at (303)424-9831| |"Don't embarrass us..." "Have I ever?" - Buckaroo Banzai | *AMIGA POWER* | `---------------------------------------------------------------------------'
d88-mbe@sm.luth.se (Michael Bergman) (07/15/90)
cseaman@sequent.UUCP (Chris "I'm Outta Here, Man!" Seaman) writes: > There's a simple, clean fix for this. Go in through HD_Toolbox, to "Partition > Drive", then click on "Advanced Options" and you'll see a box labeled "Add/ > Update Filesystems" - click this and then change the version number of the FFS > from 0 to 1. >Sorry, but this doesn't fix anything. I have had this problem since the >day I installed my 2091, and NONE of the suggested fixes have done anything. Well, your problem seems to be something else than the one mentioned with a crashing VirusX 4.0. However, as far as I know your're right in that it's not enough to change the version number. The correct fix would be to replace the FFS and all the other Workbench soft- ware with the official upgrade 1.3.2. I haven't done this myself yet but I *know* this works with the A590. Because of this, I haven't started to use VirusX 4.0 yet. Now, as I said - from what you write your problem seems to be nastier than this, but if you haven't already installed 1.3.2 you could always try it... Mike -- Michael Bergman Internet: d88-mbe@sm.luth.se // Undergrad. Comp. Eng. BITNET: d88-mbe%sm.luth.se@kth.se \X/ U of Lulea, SWEDEN ARPA: d88-mbe%sm.luth.se@ucbvax.berkeley.edu UUCP: {uunet,mcvax}!sunic.se!sm.luth.se!d88-mbe
paleo@uncecs.edu (Constantine A. LaPasha) (07/16/90)
I'v got the FastFileSystem installed properly (from the WB 1.3.2 release disk) and have tried the various other "fixes" to remedy the non-zero mem loc 0 on boot -- but no luck at getting anywhere. I assume it's something with the A2091 since it does it without my A2630 board installed, it does it even if you strip out *everything* from the startup-sequence, and does the same thing if you cold boot directly into the 2630 monitor and check the contents of that mem. The interesting thing is that I've never seen the "gdos" string there. I consistently get 0x0b 0x00 0x00 0x08 as the 1st 4 bytes. Does anyone else with this "problem" have similar symptoms?? Anybody got any clues?? -- =============================================== Kostya LaPasha paleo@ecsvax.uncecs.edu ==== ... virtually, we can do anything ... ====
ah@doc.ic.ac.uk (Angelo Haritsis) (07/16/90)
Someone mailed me a solution to this problem ( can't remember the name, sorry!) and it has worked since. That is to update the FastFileSystem to the one that came with Workbench 1.3.2. Didn't bother to try changing the version number, so not sure that works or not.
cseaman@sequent.UUCP (Chris Seaman) (07/17/90)
bscott@nyx.UUCP (Ben Scott) writes: < cseaman@sequent.UUCP (Chris "I'm Outta Here, Man!" Seaman) writes: < >bscott@nyx.UUCP (Ben Scott) writes: < >< There's a simple, clean fix for this... < > < >Sorry, but this doesn't fix anything... < < Does too does too! At least it worked like a charm on my A-590. My explanation < of the actual cause may or may not have been accurate but the fix DOES work for < me and everyone I've heard about (until now). < < >[ ... ] Whatever the problem is, it is not in the filesystem. < < You may have hit on the problem... I mean, the only thing I can think of is < that it is NOT the 2091 that's doing this to your location zero. Check every < other program in your startup (even the normal C: commands) and see if it's < one of them. If you really are running version 1 of the 1.3.2 FFS, then I think < it's unlikely that it's trashing location zero. < < And what do you mean by "many" programs failing? I never found any that < actually died - most just exhibited that weird "gdos" string showing up or < reported errors after they finished doing their jobs. At any rate a program < affected by a trashed location zero is itself buggy, usually because of trying < to use an uninitialized pointer. < < . <<<<Infinite K>>>> OK, here goes. My setup is/was not new with the 2091. It worked for over a year with a 2090a, with nary a problem. My startup sequence HAS NOT CHANGED since adding the 2091, other than to remove the commands which transferred control to the 2090a FFS partition. I have booted the machine (a 2500/20) from my generic, unmodified 1.3.2 disk, with the SAME results. I did a binary compare on the FastFileSystem which came with the 2091, and the one which came with 1.3.2, and they are identical. The file size is 12248. I am willing to try the fix suggested by Peter Cherna (although I have tried it three times already), and will report my results tomorrow. As far as which programs break, I realize that 'MANY' was probably too strong a word, but there are programs I need to use regularly that do go straight to the GURU when the address zero problem exists. These include Turbo Silver 3.0, and Post 1.1. I also realize that the fault lies with the program(s), and not with Commodore, but that doesn't correct anything. -- Chris (Insert phrase here) Seaman | /o -- -- -- cseaman@sequent <or> ||| -- -- - I'm Outta Here, Man! ...!uunet!sequent!cseaman |vvvv/ -- -- - The Home of the Killer Smiley |___/ -- -- --
terry@helios.ucsc.edu (Terry Ricketts) (07/18/90)
In article <38886@sequent.UUCP> cseaman@sequent.UUCP (Chris Seaman) writes: > >OK, here goes. My setup is/was not new with the 2091. It worked for over a >year with a 2090a, with nary a problem. My startup sequence HAS NOT CHANGED >since adding the 2091, other than to remove the commands which transferred >control to the 2090a FFS partition. I have booted the machine (a 2500/20) >from my generic, unmodified 1.3.2 disk, with the SAME results. I did a >binary compare on the FastFileSystem which came with the 2091, and the one >which came with 1.3.2, and they are identical. The file size is 12248. I >am willing to try the fix suggested by Peter Cherna (although I have tried >it three times already), and will report my results tomorrow. > >As far as which programs break, I realize that 'MANY' was probably too strong >a word, but there are programs I need to use regularly that do go straight >to the GURU when the address zero problem exists. These include Turbo Silver >3.0, and Post 1.1. I also realize that the fault lies with the program(s), >and not with Commodore, but that doesn't correct anything. > I also tried Peter's fix (exactly as he stated). It allowed virusx to come up ok but other programs seem to not function in strange ways. After putting 'zeroclear' back in my strartup-sequence everything functions normally again. I don't think that this change of file systems does much to solve the problems. Whatever it is that is causing this it is insideous, and the fix is small and simple. Until I get some more definite info on what the problem REALLY is I plan to leave 'zeroclear' in place. My son's A500 with a A590 behaves the same as my A2000 with A2091. Both work with 'zeroclear' after doing Peter's fix & don't work without it. Terry | Terry Ricketts | Internet: terry@helios.ucsc.edu | Senior Electronics Engineer | loel@helios.ucsc.edu | Lick Observatory Electronics Lab | Phone: 408-459-2110 | University of Calif, Santa Cruz |
brian@sky.COM (Brian Pelletier) (07/19/90)
In article <5244@darkstar.ucsc.edu> terry@helios.ucsc.edu (Terry Ricketts) writes: > I also tried Peter's fix (exactly as he stated). It allowed virusx to come >up ok but other programs seem to not function in strange ways. After putting >'zeroclear' back in my strartup-sequence everything functions normally again. >I don't think that this change of file systems does much to solve the problems. >Whatever it is that is causing this it is insideous, and the fix is small and >simple. Until I get some more definite info on what the problem REALLY is I >plan to leave 'zeroclear' in place. My son's A500 with a A590 behaves the same >as my A2000 with A2091. Both work with 'zeroclear' after doing Peter's fix & >don't work without it. > Terry > > >| Terry Ricketts | Internet: terry@helios.ucsc.edu >| Senior Electronics Engineer | loel@helios.ucsc.edu >| Lick Observatory Electronics Lab | Phone: 408-459-2110 >| University of Calif, Santa Cruz | Just to 'chime in' with the rest of you here, I also have a 2091 with the same mysterious problem. I started a thread on the subject a few months back on c.s.a.t., but I finally got frustrated by everyone telling me to do the same old thing (which never worked for me at all...). I have 590fix in my startup sequence, and now everything behaves normally. The only exceptions to this are a few games that must boot from floppy. Some of these still won't work if the 2091 is automounted at powerup..... -Brian +=========================================================================+ | Brian Pelletier Disclaimer: These are MY opinions, not SKY's.| | Sky Computer | | UUCP - brian@sky.com (work) pelletier@grove.UUCP (home) | +=========================================================================+
acs@pccuts.pcc.amdahl.com (Tony Sumrall) (07/24/90)
In article <1990Jul16.023510.12197@uncecs.edu> paleo@uncecs.edu (Constantine A. LaPasha) writes: > > >I'v got the FastFileSystem installed properly (from the WB 1.3.2 > ... > >The interesting thing is that I've never seen the "gdos" string there. >I consistently get 0x0b 0x00 0x00 0x08 as the 1st 4 bytes. > >Does anyone else with this "problem" have similar symptoms?? >Anybody got any clues?? I have exactly the same value stored in location zero on my machine. I, too, have tried all of the suggested fixes and none of them help. >Kostya LaPasha paleo@ecsvax.uncecs.edu -- Tony Sumrall responsible for VT100 2.9B (and 2.9A and 2.9 and 2.8a and...) acs@pccuts.pcc.amdahl.com <=> amdahl!pccuts!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
phorgan@cup.portal.com (Patrick John Horgan) (07/24/90)
In article <1990Jul16.023510.12197@uncecs.edu> paleo@uncecs.edu (Constantine A. LaPasha) writes: > >The interesting thing is that I've never seen the "gdos" string there. >I consistently get 0x0b 0x00 0x00 0x08 as the 1st 4 bytes. > I too get this string. I got it before I switched to the fast-file sytem, though. Wish I know why:( Patrick Horgan phorgan@cup.portal.com
cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) (07/25/90)
In article <32023@cup.portal.com> (Patrick John Horgan) writes: >I too get this string. I got it before I switched to the fast-file >sytem, though. Wish I know why:( Because someone puts it there. Boot a virgin workbench and see if you get that string. Then try eliminating things from your startup sequence one by one and checking for it to disappear. -- --Chuck McManis Sun Microsystems uucp: {anywhere}!sun!cmcmanis BIX: <none> Internet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "I tell you this parrot is bleeding deceased!"
wfh58@leah.Albany.Edu (William F. Hammond) (07/26/90)
In article <139472@sun.Eng.Sun.COM> cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) writes: >In article <32023@cup.portal.com> (Patrick John Horgan) writes: >>I too get this string. I got it before I switched to the fast-file >>sytem, though. Wish I know why:( > >Because someone puts it there. Boot a virgin workbench and see if you > . . . First, as far as I am concerned, the longword at location 0 belongs to Commodore-Amiga. Having said that, let me say that a friend was having trouble with an item and became concerned about this issue. So we concocted a "look" utility to see what's there and a "poke" to zero out the longword at location 0. It seems to be the case that using the "lock" command to change the write protect status of dh0: (vanilla 2500/30 with A2091) will cause the hex value 0B000008 to be placed in the longword at location 0. I don't know why, and I don't know whether there are other ways to provoke it. I have never seen any other non-NULL value sitting there. ---------------------------------------------------------------------- William F. Hammond Dept. of Mathematics & Statistics 518-442-4625 SUNYA, Albany, NY 12222 wfh58@leah.albany.edu wfh58@albnyvms.bitnet ----------------------------------------------------------------------
olson@uhccux.uhcc.Hawaii.Edu (Todd Olson) (07/27/90)
In article <3398@leah.Albany.Edu>, wfh58@leah.Albany.Edu (William F. Hammond) writes: > It seems to be the case that using the "lock" command to change the > write protect status of dh0: (vanilla 2500/30 with A2091) will cause > the hex value 0B000008 to be placed in the longword at location 0. > I don't know why, and I don't know whether there are other ways to > provoke it. I have never seen any other non-NULL value sitting there. > That is the value I also have in long word zero with my 2091 installed. I would like to have an official fix as the change the filesystem method does NOT work. I purchased the controller and the hard drive at different times so there was not a debuging version of the FFS on my drive when I purchased it. The update file system DOES NOT WORK, I have tried booting up with a new copy of WB1.3.2 then do a ctrl-d and it is 0B000008. Is there a REAL fix? > ---------------------------------------------------------------------- > William F. Hammond Dept. of Mathematics & Statistics > 518-442-4625 SUNYA, Albany, NY 12222 > wfh58@leah.albany.edu wfh58@albnyvms.bitnet > ----------------------------------------------------------------------
Eric.Sanders@f210.n110.z1.FIDONET.ORG (Eric Sanders) (09/01/90)
AREA:UUCP_AMIGA
I used to run a short program called 590fix in my startup-sequence
which took care of the problem. I never saw any system messages
refer for gdos either before I found the fix.
--
----------------------------------------------------------------------------
AFIT Amiga Users BBS/UFGateway |Eric Sanders - via FidoNet node 1:110/300
1:110/300 Dayton, Ohio |UUCP: afitamy!210!Eric.Sanders
(513)-252-7681 |ARPA: Eric.Sanders@f210.n110.z1.FIDONET.ORG
----------------------------------------------------------------------------