CompuServe Thread

GVP-BaseBoard Conflicts?

16 messages in this thread
#54942From: Len LekxApr 15, 1992 1:25 PM
I'm running an Amiga 500 with a 4.5-Meg BaseBoard in my memory expansion slot. I also have a GVP Series II hard drive with an empty RAM expansion area. I'd like to use that area to expand my 500 more, but I'm afraid of memory conflicts. Some of the BaseBoard memory is mapped into the AutoConfig space (which I assume the GVP uses) and I'm worried that the overlapping memory boards will cause errors. Is anyone aware of this sort of thing being tried before? If so, what was the outcome? I'm *really* not all that willing to experiment with the only computer I have, but I also don't want to give up all the memory I have. Help? Len Lekx [73300,723]
#54975From: Dean BrownApr 15, 1992 8:43 PM
Len, I'd strongly suggest against trying to mix the GVP ram and the BaseBoard ram. There WILL be conflicts, and you won't like the results. In all honesty, any memory expansion for the A500 that plugs into the trap door that is larger than the standard 512K is not such a good idea. While the expansion is cheap, it is also subject to the CHIP memory bandwidth problems that show up when you use 8 or 16 color hires screens. (ie.. it is not FAST ram, nor is it CHIP ram, it's just SLOW ram) They also are not designed according to the system interface specs, which causes problems when you wish to add additional devices. (your GVP memory as an example) Dean DKB Software
#55111From: Len LekxApr 17, 1992 10:03 AM
Dean- >There WILL be conflicts, and you won't like the results. I understood that. (*SIGH*) But I already _have_ the BaseBoard, and have had it fully occupied for years now. I just got the GVP, and was wondering about adding memory to it. Since some of the memory on the BaseBoard isn't in the AutoConfig space, I think I might just be able to get away with removing some of the chips from the BaseBoard, and installing RAM in the GVP slots to make up for it. (Looking at the BB's memory map, I figure I lose about 1/2 meg for every 2 I install. If I limit myself to the cheaper 1-meg SIMMS, I can get 7.5-megs of memory by taking out two rows of BaseBoard chips.) Thanx for the note. Len Lekx [73300,723]
#55150From: Dean BrownApr 17, 1992 9:12 PM
Len, I'm afraid that won't work either. Due to the way the BaseBoard software works, you'll end up with several chunks of your GVP memory added into the system memory lists twice. If you're lucky you'll get an immediate GURU or lockup. If you're not lucky, you might get far enough into an application to lose some valuable data. The trap door RAM expansions are really bad hacks. They work fine in the system by themselves, but the minute you add something extra to the machine all bets are off. Dean DKB Software
#55186From: Len LekxApr 18, 1992 9:18 AM
Dean- Well, if that don't take the cake! (^_^) Pity, it means that I'm going to have to get $300 worth of SIMMS for the GVP to make up for all the memory I have on the BaseBoard. (Oh well, at least I won't have to worry now about that bigger power supply I was thinking of getting.) Ah well, maybe I'll get lucky and be able to sell the BaseBoard to some other 500 user who doesn't have a hard drive (*_*) Len Lekx [73300,723]
#55247From: Dean BrownApr 19, 1992 8:13 AM
Len, I may have given you the wrong impression. The HD should not have any problem with the BaseBoard or any other trap door RAM expansion. Memory expansion is quite risky though. What kind and how many SIMMs does your GVP require to expand your memory to what you have on the BaseBoard? $300 seems excessive for 4 megs. (if that is what you meant) Dean DKB Software
#55261From: Len LekxApr 19, 1992 11:04 AM
Dean- >The HD should not have any problem with the BaseBoard or any other trap door >RAM expansion. Memory expansion is quite risky though. I took some time to map out the areas of memory the BB places its memory in. I think I'd be safer just taking the BB out and putting the memory in the GVP. It might also do wawy with the GURU errors I've been getting (8000 0003-B – corrupt memory, I think) If I want to expand to what the BaseBoard has (4 meg) it requires 4 1-Meg SIMMS. If I want to go further (8 Megs) it takes 2 4-Meg SIMMS. I've been going to local computer stores comparing prices, and the lowest price I've gotten is $55 (CDN) for one 1-Meg SIMM – making a 4-meg expansion total $220. Add a total of 15% taxes, it adds up to $253. (Not $300, but close) If I want to go to 8 Megs, well, I think they're around $150 each up here. Len Lekx [73300,723]
#55385From: Dean BrownApr 20, 1992 9:23 PM
Len, My math says you should go for the 2 4Meg SIMMS. $150 x 2 + 15% = $345 for 8Megs. Or $92 for the additional 4Megs. Dean DKB Software
#55436From: Len LekxApr 21, 1992 9:52 AM
Dean- The $150 price for 4Meg SIMMS might be the American price. After all, you can get 1Meg SIMMS for less than $40 down there. (^_^) So you can figure that a 4Meg SIMM up here would cost somewhere around $180. So… 180 x 2 + 15% = $414. Not the kind of dough I have on hand at the moment. (^_-) Len Lekx [73300,723]
#55219From: ICD, Inc.Apr 18, 1992 8:40 PM
That's a pretty general condemnation of A501 slot memory expansion devices. I assume you've tested them all? Craig
#55225From: Dean BrownApr 18, 1992 10:33 PM
Craig, I've looked at quite a number of them, and they all work in a very similar manner. If anything I said was incorrect or misleading, please point it out to me. I'd be more than willing to listen to any corrections you might have. Dean DKB Software
#55250From: ICD, Inc.Apr 19, 1992 9:22 AM
What you said was "The trap door RAM expansions are really bad hacks." How do you define a "really bad hack"? "They work fine in the system by themselves, but the minute you add something else to the machine all bets are off." Do you have examples for all trap door RAM expansions to support this statement? The statement implies that none of them work with any additional hardware and is a very general condemnation (but not as general as "really bad hack"). Craig
#55384From: Dean BrownApr 20, 1992 9:23 PM
Craig, Really bad hack is my opinion, one that I'll stand by. The trap door RAM expansion products hard code themselves into the autoconfig memory space _without_ autoconfiguring. This means that the system has no way of knowing where to put any additional devices if they are added on. (…all bets are off…) Chances are that there _will_ be a conflict under such circumstances. A hack by my definition is a product that does not install in a system defined manner. I sell products that fit that description when there is no other way to provide the functionality. A bad hack is one that ignores system conventions when a supportable method exists. Dean DKB Software
#55459From: ICD, Inc.Apr 21, 1992 6:35 PM
Still no details? Still no specific examples? That's what I asked for. Craig
#55478From: Dean BrownApr 21, 1992 8:30 PM
Craig, What do you want? Product names, Company names? an RWAR?… Sorry, that's not why I'm here. Somebody asked a question and I answered it, I'm sorry you didn't like the answer. Relating to the specific product in question the answer is perfectly correct. It WON'T work. Dean DKB Software
#55530From: ICD, Inc.Apr 22, 1992 6:07 AM
Yes, but you didn't answer for the specific product in questions; you answered for a class of product where the answer is _not_ the same. Craig