dwi@manta.NOSC.MIL (Steve Stamper) (04/29/89)
The new Rev 6.0 Amiga 2500 I have seems to hate booting AMigaDOS in the 68000 Mode. It can boot diskettes that do not use standard AmigaDOS in 68000 mode, But it cannot Boot any AmigaDOS disks (including HardDisk) in 68000 mode. Any ideas Why? I get a "recoverable alert" 4.0021DA40 at 1st when I continue I get a 3.00212A00 GURU. All is 100% fine in 68020 mode. My old rev 4.6 AMiga 2000 with A2620 booted all things fine in either mode. Any idea Why the Machine will not boot AmigaDOS in 000 mode? -Roger Uzun
root@dialog.UUCP (Christian Motz) (05/03/89)
In article <780@manta.NOSC.MIL> dwi@manta.NOSC.MIL (Steve Stamper) writes: > >[...] > >I get a "recoverable alert" 4.0021DA40 at 1st when I continue I >get a 3.00212A00 GURU. All is 100% fine in 68020 mode. >My old rev 4.6 AMiga 2000 with A2620 booted all things fine in >either mode. I just got my new Rev. 6 A2000 myself, and while I *LOVE* the 1 MB Chip RAM, it seems as if the machine is not as stable as my old Rev. 4.4. Very often the machine Gurus on bootup, much the same as Steve described above. I have the original A2090 with a Rodime 40 MByte SCSI HD. A friend of mine has experienced similar problems, in fact, it looks as if his 2 MByte RAM Card (also the original Commodore Expansion, I don't remember the model) doesn't work properly with the new Rev. mainboard (the machine becomes *VERY* unstable and crashes frequently, i.e. when Zoo is started), while it works perfectly with a Rev. 4.4 board. >From the experience I have (ok, ok, so it is based on only two samples of the new board) I can only *WARN* people not to get stuck with the current Rev. 6 board. While it looks tempting at first sight, it seems like a real bummer to me. Could anyone from C=A clarify what has been changed on the new mainboard? What for example is the upside down piggyback PCB near Agnus for? Has the bus timing changed and is it possible that older expansion boards don't work? I (and I am sure quite a few people) would appreciate any comment. Dave, are you listening? -- Christian Motz uucp: ...!uunet!mcvax!unido!pfm!nadia!dialog!root "Trust me, I know what I'm doing!" -- Sledge Hammer Bix: cmotz
dwi@manta.NOSC.MIL (Steve Stamper) (05/04/89)
The problem with my rev 6 system was the 16 bit expansion RAM board I had, 8-up!. It was not compatible with the rev 6 amiga so any pgm which used memory there crashed. It may have been my individual 8-up! board, it ran in all rev 4.X machines. Also some programs with bugs that were non fatal in 512k CHIP ram now are fatal in 1M CHIP RAM. -Roger
jimm@amiga.UUCP (Jim Mackraz) (05/05/89)
In article <788@manta.NOSC.MIL> dwi@manta.nosc.mil.UUCP (Steve Stamper) writes:
)The problem with my rev 6 system was the 16 bit expansion RAM board
)I had, 8-up!. It was not compatible with the rev 6 amiga so
)any pgm which used memory there crashed. It may have been my individual
)8-up! board, it ran in all rev 4.X machines. Also some programs
)with bugs that were non fatal in 512k CHIP ram now are fatal in
)1M CHIP RAM.
)
)-Roger
Note that if a program ever specifically asks for MEMF_FAST, and there
is no non-chip ram, that allocation will fail. It is best not to specify
memory type if you don't need chip ram, so that you will get FAST if
available, but CHIP, if not.
The 1MB chip system is the first time in a long time that there is
not fast ram on board, first ever if the program "requires 1MB".
So, programmers: beware: MEMF_FAST is probably NEVER appropriate (since the
memory might not be particularly fast, anyway).
Rev 6 users: once you get some fast memory in there that doesn't break,
you should be OK, and we'd like to hear if there are software problems
on Rev 6 or other 1MB chip configurations if sufficient fast ram is
present.
I recommend populating the 2620 board. It IS populated? Well, that's
different: somebody must be cheating on the high address byte.
Leap all over the software vendor: have them contact C-A if they think
the problems are not their fault ... ;^)
jimm
--
Jim Mackraz, I and I Computing "He's hidden now, but you can see
{cbmvax,well,oliveb}!amiga!jimm The bubbles where he breathes."
- Shriekback
Opinions are my own. Comments are not to be taken as Commodore official policy.daveh@cbmvax.UUCP (Dave Haynie) (05/06/89)
in article <576@dialog.UUCP>, root@dialog.UUCP (Christian Motz) says: > In article <780@manta.NOSC.MIL> dwi@manta.NOSC.MIL (Steve Stamper) writes: > I just got my new Rev. 6 A2000 myself, and while I *LOVE* the 1 MB > Chip RAM, it seems as if the machine is not as stable as my old > Rev. 4.4. There's no obvious reason for this. I wasn't the only one working on the Rev 6 board, but the only thing I did to it was change the motherboard memory system. If anything, I'd expect it to be a little more forgiving that the older systems -- you can't really get 150ns DRAMs in the 1 meg package, so we use 120s, which would increase the chip bus timing margins considerably. As far as I know, nothing was changed that should have any effect on the expansion bus. > unstable and crashes frequently, i.e. when Zoo is started), while > it works perfectly with a Rev. 4.4 board. > Could anyone from C=A clarify what has been changed on the new > mainboard? What for example is the upside down piggyback PCB near > Agnus for? That's a tower to allow the system to use static column memories instead of the normal memory. Should not change anything. > Has the bus timing changed and is it possible that older expansion boards > don't work? I (and I am sure quite a few people) would appreciate any > comment. Dave, are you listening? The only thing that's likely to change bus timing in the new system is the 1 meg Agnus, but it actually changes timing for the better. Agnus creates the system clocks: C1, C3, CDAC*, and 7MHz. Old Agnus was a tad sloppy, in that the C1/C3 to CDAC*/7MHz skew jittered more that we'd have liked. The new Agnus makes the clocks differently, and as a result they're much more stable. Though I'm open to any specific examples of trouble -- we can certainly look for any problems on this end if we have an idea of what to look for. > Christian Motz uucp: ...!uunet!mcvax!unido!pfm!nadia!dialog!root > "Trust me, I know what I'm doing!" -- Sledge Hammer Bix: cmotz -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
daveh@cbmvax.UUCP (Dave Haynie) (05/06/89)
in article <3801@amiga.UUCP>, jimm@amiga.UUCP (Jim Mackraz) says: > I recommend populating the 2620 board. It IS populated? Well, that's > different: somebody must be cheating on the high address byte. In the context of A2620/A2500 systems using SetCPU V1.4 with the FASTROM option, I have reliable reports that both recent version of Zoo and Arc break with a bus error (GURU #2) exception. They're likely writing to something that SetCPU protects. While the problem is in the offending program, the next release of SetCPU (V1.5, in Gamma testing at the moment) will handle trap the level 2 exception for errant writes to protected memory, which at the moment seems to let both Zoo and Arc run OK. > Leap all over the software vendor: have them contact C-A if they think > the problems are not their fault ... ;^) Yup. Even if it's fixable with patches like the aforementioned SetCPU trap handler, it's far better to be right in the first place. > jimm -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
dwi@manta.NOSC.MIL (Steve Stamper) (05/06/89)
The problem with my rev 6 board was it did not like the RAM on the 8-UP! card I had in there. All of the rev 4.X machines liked the 8-up! card though. The good news is I sold the 8-UP! for $400.00 and bought myself 2M of the 424256V-10 chips for my a2620 for $256.00. So i now have 4M of 32 bit ram and a profit! BTW Is there any performance increase in going to 80ns DRAMS on the A2620. I mean I would not go through the trouble to remove the 100ns RAM on the Card now, but if one did what kind of performance boost would one get. I myself am going to have enough trouble arc welding in the 100ns DRAMS I just got! -Roger
space@nadia.UUCP (Lars Soltau) (05/07/89)
In article <6782@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >Though I'm open to any specific examples of >trouble -- we can certainly look for any problems on this end if we have >an idea of what to look for. >-- >Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy > Amiga -- It's not just a job, it's an obsession Sounds encouraging. OK, here we go! I have a Commodore 2052 2MB Expansion Board, Rev. 3, which worked fine on my old B2000. When I got an B2000 with the new Rev.6 motherboard, things started to get very unstable. Whenever I started something that used a lot of RAM (zoo, multiple NetHacks/DMEs), the machine crashed with various Gurus: sometimes #3.X, sometimes "wrong library checksum" (forgot the number). At first I thought my RAM board was flaky, so I borrowed a B2000, Rev. 4.4, which hasn't had a single Guru since I installed the 2052. I am using FastMemFirst, so the $200000 RAM gets used all right. My last hope was that my Rev.6 B2000 was the troublemaker. But today I tried my RAM card with Christian's Rev.6 B2000 and in the progress we damaged his file system so that he had to reformat his hard drive. At first we could start 4 copies of nethack, the fifth caused a Guru. Then, after a reboot, the 2nd nethack crashed. Dave, you wrote something about switching from 150ns to 120ns RAMs. My 2052 has 150ns DRAMs, might that be the cause of my problems? I hope the information I gave you is sufficient for you to find a solution to my problem. I am anxiously waiting for your reply, since I will soon have to decide which B2000 to keep. While I'd very much like the 1MB Chip RAM, it would break my heart if I'd have to part with my 2MB card. -- Lars Soltau UUCP: ...uunet!unido!pfm!nadia!space BIX: -- no bucks --